[security-dev] Multi-application support for IDM

Rodney Russ rruss at redhat.com
Mon Nov 12 11:08:51 EST 2012 

I believe that we would want to support both use cases.  The first one for customers to manager their users bases for applications deployed.  The second for support of OpenShift public and private deployments.

----- "Pete Muir" <pmuir at redhat.com> wrote:

> This seems to work to me.
> 
> On 12 Nov 2012, at 00:56, Shane Bryzak wrote:
> 
> > Actually, after some more thought there may be a third option in
> which
> > we can support both scenarios. Until now we've assumed both "realm"
> and
> > "application" are the same thing, a kind of "subgrouping" of
> identity
> > state (the naming of which is even slightly contentious).  However,
> what
> > if we supported them both?  By introducing a hierarchy with the
> Realm at
> > the top, we can then support both scenario A (by making both Users
> and
> > Applications unique within a Realm) and scenario B (by making Realms
> > totally separate to each other).
> >
> > This would require a slightly more complex (but still intuitive)
> API.
> > Here's some examples based on a fictional paper company:
> >
> > a) Creating a new user "dschrute" in realm "corporate"
> >
> > identityManager
> >     .forRealm(identityManager.getRealm("corporate"))
> >     .createUser(new SimpleUser("dschrute"));
> >
> > b) Adding this new user to the "sales" Group, in application "cms":
> >
> > Realm corporate = identityManager.getRealm("corporate");
> > Application cms = identityManager.getApplication(corporate, "cms");
> > Group sales = identityManager.getGroup(cms, "sales");
> > User user = identityManager.getUser(corporate, "dschrute");
> >
> > identityManager
> >     .forApplication(cms)
> >     .addToGroup(user, sales);
> >
> > c) Creating a retail customer user and adding them to the
> "customers" group:
> >
> > Realm retail = identityManager.getRealm("retail");
> > Application onlineSales = identityManager.getApplication(retail,
> > "onlineSales");
> > User user = new SimpleUser("bvance");
> > Group customers = identityManager.getGroup(onlineSales,
> "customers");
> >
> > identityManager
> >     .forRealm(retail)
> >     .createUser(user);
> >
> > identityManager
> >     .forApplication(onlineSales);
> >     .addToGroup(user, customers);
> >
> >
> > From the above examples, we can see that Users are specific to
> Realms,
> > while Groups, Roles and Memberships are specific to Applications. 
> I'm
> > kind of wondering if we should make Group unique to the Realm
> instead of
> > the Application (and just leave Roles and Memberships as
> > Application-specific) as this might be a more sensible structure
> when it
> > comes to modeling real life scenarios.  If you have an opinion
> either
> > way please let me know what you think.
> >
> >
> > On 11/12/2012 10:19 AM, Shane Bryzak wrote:
> >> I think we need to decide on exactly what level of identity
> segregation
> >> is going to be supported between each realm/application.  One
> possible
> >> scenario (let's call it scenario A) is that a single User might
> have
> >> access to multiple applications, but different permissions within
> those
> >> applications.  In this scenario, there would be a single User
> record,
> >> then a separate set of Role/Group/Membership records for that User
> >> within each realm/application.  An example use case for this might
> be
> >> jboss.org, where a User uses their JBoss login to access multiple
> >> "applications" (for example JBoss Forums, JIRA, Wiki, etc).
> >>
> >> Scenario B is what I would describe as the "multi-tenant" scenario,
> >> where a single identity store may be used to serve multiple,
> separate
> >> applications.  In this scenario, each realm/application has its own
> User
> >> database which exists for that realm alone.  In contrast to
> scenario A,
> >> User "jsmith" in one realm would be a totally different User record
> to
> >> "jsmith" in another realm.
> >>
> >> I think we need to make a firm decision on this before we proceed
> any
> >> further.
> >>
> >> On 11/10/2012 01:34 AM, Pete Muir wrote:
> >>> Inline.
> >>>
> >>> On 8 Nov 2012, at 17:08, Bolesław Dawidowicz wrote:
> >>>
> >>>> 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.
> >>> Agreed, we're going to need both scenarios in order to support
> some sort of IDM service, that can serve multiple applications,
> regardless of whether it is in VM or remote.
> >>>
> >>>> 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.
> >>> I have a feeling that we should be quite flexible here. One way to
> do this that I think could work, and keeps the programming model quite
> normalised is to provide some sort of MultiplexingIdentityStore out of
> the box, which is capable of routing the request to the right actual
> identity store.
> >>>
> >>>> 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);
> >>> I think this needs to be up to the IdentityStore impl in use. To
> carry on my previous point, if you built this around a delegation
> model, we could provide a base delegating identity store, which the
> user can override methods on to change the delegation strategies.
> >>>
> >>>> 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 at redhat.com>
> >>>>> To: security-dev at 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.
> >>> Agreed.
> >>>
> >>>>> Maybe only piece you are missing is some method in
> IdentityManager to
> >>>>> identify current context it is referring to.
> getCurrentApplication() ?
> >>> I think this is something that should be provided by the
> integrator, not by the IDM. The way of establishing the current
> application varies completely by what wiring you use (e.g. CDI vs JNDI
> vs MSC vs OSGi etc.) We need to keep the IDM totally free of wiring
> concepts IMO.
> >>>
> >>> Also, a wiring system typically has a much more flexible approach
> to this e.g.
> >>>
> >>> @Inject @Current
> >>> Application a;
> >>>
> >>> or
> >>>
> >>> context.lookup("java:comp/Application")
> >>>
> >>>>> 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.
> >>> Tenant? Generally speaking, applications are tenants of the
> application server, an application can be divided into various tenants
> etc.
> >>>
> >>>>> 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.
> >>> We split the JPA schema out into a separate module already, which
> looks like a vey good decision, as now we just produce a simple
> schema, and a multi-tennant schema for ootb use.
> >>>
> >>>>> 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
> >>>>>>
> >>>>> _______________________________________________
> >>>>> security-dev mailing list
> >>>>> security-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/security-dev
> >>>>>
> >>>> _______________________________________________
> >>>> security-dev mailing list
> >>>> security-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/security-dev
> >>> _______________________________________________
> >>> security-dev mailing list
> >>> security-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/security-dev
> >> _______________________________________________
> >> security-dev mailing list
> >> security-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/security-dev
> >
> > _______________________________________________
> > security-dev mailing list
> > security-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/security-dev
> 
> 
> _______________________________________________
> 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