Re: [security-dev] Multi-application support for IDM

Both scenarios. For example we have a default realm/application used by several webaps - they all just share idm data. Most simple usecase is company wide IDM service with all the stuff roster and etc. Then few other webapps have isolated user data.

I imagine we should have some flexibility in the configuration. So default is that each "application" contains separate isolated IDM data. Either it is single IdentityStore implementation or one shared instance supporting multitenency. I think it should be also possible to preconfigure some application/realm with fixed IdentityStore instance - like for LDAP. Then in second case question is how to implement it. Putting everything in one table schema won't scale well with growing number of applications so I imagine another option would be to to have isolated table set per application.

Basically cloud use case mentioned before requires adding new isolated application/realm on the fly without restarting the service. So this method void createApplication(Application application);

should create isolated space using default JPA store or create new JPA store instance using some defaults. There are some discussions around multitenancy in JPA and Hibernate btw: https://community.jboss.org/wiki/Multi-tenancyDesign https://hibernate.onjira.com/browse/HHH-5697 Can be worth checking. On 11/08/2012 03:39 PM, Pedro Igor Silva wrote: > Each application may have/use its own identity store ? Or are we talking about a consolidated store shared by all applications ? > > Today the API only supports one identity store per identity manager instance. Wondering if should provide support for multiple stores too, and give to users features like identity syncronization, for example. > > Regards. > Pedro Igor > > ----- Original Message ----- > From: "Bolesław Dawidowicz" <bdawidow(a)redhat.com&gt; > To: security-dev(a)lists.jboss.org > Sent: Thursday, November 8, 2012 10:56:20 AM > Subject: Re: [security-dev] Multi-application support for IDM > > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/security-dev >> > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev