[security-dev] Multi-application support for IDM

Bolesław Dawidowicz bdawidow at redhat.com
Thu Nov 8 07:56:20 EST 2012


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.

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?
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>



More information about the security-dev mailing list