[security-dev] Multi-application support for IDM

[Anil Saldhana]

On 11/08/2012 06:56 AM, Bolesław Dawidowicz wrote:
> I like it very much. Tried to think about proper solution myself
> yesterday a bit and didn't manage to come up with anything better. What
> I like is that IdentityStore and whole model is not polluted with
> something outside of identity objects domain.
>
> Maybe only piece you are missing is some method in IdentityManager to
> identify current context it is referring to. getCurrentApplication() ?
>
> I'm not perfectly convinced that application is the proper naming
> though. Realm, domain, partition? All in all I imagine that for many
> applications it will be handy to reuse same storage space. In
> application server environment it would be really handy to just
> associate application with some idm context and configure all the rest
> with UI console. If we bridge it together with authorization api and
> users can easily configure application scoped resources that way it
> would be fairly powerful. On the other hand thinking about cloud usecase
> name "application" provides quite clear definition of context.
Yeah. I had the same thoughts as you. "Application" may be bad term 
here. Some systems use "Realm" in this context. Others use "Domain". You 
mention Partition also. We can choose maybe "realm" to keep it 
consistent with majority of usage?

>
> As for implementation I think it is useful to both have simple multi
> tenant model with application built into schema and clear isolated table
> set per application one. Mainly for the sake of scalability. In both
> scenarios being able to add new applications on the fly.
> IdentityStoreInvocationContext concept is flexible enough to handle it
> within single JPAIdentityStore instance
> Configuration is probably quite wide separate concern but maybe for a
> separate discussion so I won't hijack this thread for it.
>
> On 11/08/2012 12:27 PM, Shane Bryzak wrote:
>> I've been thinking about Bill's request for multi-application support,
>> and I think I've come up with a solution that's going to be minimally
>> disruptive to the existing API.  For starters, we need to add a few
>> methods to IdentityManager to support application management:
>>
>> void createApplication(Application application);
>>
>> void removeApplication(Application application);
>>
>> Application getApplication(String applicationId);
>>
>> Collection<Application> getAllApplications();
>>
>> (The getAllApplications() method is necessary as the Query API only
>> deals with IdentityTypes, of which Application isn't one).
>>
>> The next step is to allow the Application to be set somehow for any
>> given identity management operation.  I think the easiest way to do this
>> is by providing a new method called forApplication():
>>
>> IdentityManager forApplication(Application application);
>>
>> The forApplication() method returns an instance of IdentityManager for
>> which any operations performed will be within the context of the
>> specified Application.  Let's take a look at this in more practical
>> terms - for example, pretend we want to grant the "moderator" role to
>> user "bill" for the application "JBossForums".  The code would look like
>> this:
>>
>> Application jbossForums = identityManager.getApplication("jbossForums");
>>
>> IdentityManager im = identityManager.forApplication(jbossForums);
>>
>> User bill = im.getUser("bill");
>> Role moderator = im.getRole("moderator");
>> im.grantApplicationRole(bill, moderator);
>>
>> The selected Application is passed to the underlying IdentityStores via
>> the IdentityStoreInvocationContext, to which we will add a
>> getApplication() method.  We can also support multi-application
>> configuration, where one application might use an LDAP-based identity
>> store, while another might use a File-based identity store.
>>
>> By providing multi-application support in this way, we can maintain the
>> existing API (we don't need to refactor every single method to add an
>> Application parameter) and for the consumers who don't care about
>> multi-application support the feature won't get in their way. We can
>> then very easily expose the IDM API as a set of RESTful web services to
>> achieve a standalone identity management service.
>>
>> What do you guys think?