[security-dev] Multi-application support for IDM
Bolesław Dawidowicz
bdawidow at redhat.com
Thu Nov 8 11:13:46 EST 2012
On 11/08/2012 03:13 PM, Anil Saldhana wrote:
> 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?
I'm not really comfortable with any of those options somehow. In some
use cases application feels more natural and in some realm seems better.
Would be good if others comment on their perception as well.
>
>>
>> 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