[security-dev] IDM Realms and Applications - The Nitty Gritty

[Shane Bryzak]

I wouldn't say I've had a eureka moment, but I think this might be one 
step closer to a solution:

Realm design take 2

Here's the major points:

1) We differentiate between standard roles and application roles. 
Standard roles are now defined by the realm, while application roles are 
now defined by the individual application.
2. Groups still remain as realm-specific.  This is mainly to address the 
"corporate" use case, however it's still possible to use groups within 
an "ASP" use case by simply mirroring the groups across all realms.  
Although for the ASP use case, my recommendation would just be to 
implement application security based on application roles and permissions.

I *think* that this design offers us a happy medium that addresses all 
use cases sufficiently, while remaining relatively simple. Feedback of 
course is welcome.


On 11/15/2012 07:26 AM, Shane Bryzak wrote:
> On 11/15/2012 05:17 AM, David M. Lloyd wrote:
>> A couple more use case tidbits...
>>
>> Connecting roles to applications is sensible in the respect that most
>> roles are application-specific, however it seems plausible that one
>> might want to have a role which spans applications.
> Possibly yes, especially for roles such as "John Smith is the Manager of
> the IT Department".  It's feasible that a company might wish to deploy
> multiple applications in which such a role would be relevant.
>
> There's (at least) two major use cases that we need to consider in our
> design.  The first use case, which I'll refer to as the "ASP use case"
> (Application Service Provider) is the one where a vendor provides an
> application that can be used by multiple clients.  A real life example
> of this is OrangeHRM (which we ourselves use for managing employee
> leave).  Each customer gets their own realm (keeping identity state
> separate from other customers) and the application defines its own
> groups, roles and permissions.
>
> The second one is the "Corporate" use case.  In this use case, there is
> a single realm that contains all of the identity state defining users
> and groups that represent the organizational structure of the company.
> There may be one or more applications that authenticate from this realm,
> each one controlling access based on the user's group and/or role
> memberships.
>
> Since yesterday I've been wracking my brain trying to work out a design
> that elegantly addresses both of these use cases while not violating
> KISS, however I've been unsuccessful so far.  The issue mainly lies in
> the placement of groups and roles - on one side, it seems to make sense
> to maintain groups within the realm.  This is reinforced by the
> corporate use case in which you should be able to define your corporate
> structure once, then leverage off that structure to control individual
> application service privileges.  On the other hand, this doesn't make
> sense in the ASP use case (where everything is application-oriented).
> Perhaps the answer lies in not supporting groups for the ASP use case...
> in any case I need to think about this some more.
>
>
>> Also it seems that there is a (conceptual) equivalency between roles and simple permissions
>> (in the java.security.Permission sense).  Is that equivalency ever
>> formalized anywhere, particularly in the context of a security manager?
> There's not really an equivalency here, we do support a full-fledged
> (separate) permissions API that supports this style of simple permission.
>
>> Finally it seems to me that there may be benefit in identity-oriented
>> storage for things like application preferences and that sort of thing.
>>     Is there any allowance for this concept in this IDM model?
> I would use Attributes to store this kind of data.
>
>> On 11/13/2012 09:04 PM, Shane Bryzak wrote:
>>> On 11/14/2012 12:24 PM, David M. Lloyd wrote:
>>>> I'm not sure I understand the rationale of the relationship between
>>>> realms and applications.
>>>>
>>>> To me the concept of a "realm" in terms of identity management relates
>>>> more to segregating users into groups based on organizational and
>>>> technological realities.  For example, if I am hosting a multi-tenant
>>>> application I might have a realm for each of my customers (but only one
>>>> or a few application(s)).  For another example, I might have a realm for
>>>> application authentication (i.e. regular users), a realm for
>>>> computer-to-computer authentication (might be identified by public key
>>>> or certificate or some other atypical principal type), and a realm for
>>>> administration, all of which are utilized by one or a few application(s).
>>> That's a good point and a valid use case that I thought I had taken into
>>> consideration, however thinking about it a little deeper there are some
>>> nuances of the design that have question marks over them. Let me think
>>> about it a little more and I'll get back to you.
>>>
>>>> Unless I'm grossly misunderstanding the concepts (a very real
>>>> possibility), it seems like applications should be decoupled from realms
>>>> completely.
>>> Possibly, and while it's relatively clear that Users would remain within
>>> the Realm and Roles would remain defined by the Application, I'm not
>>> quite sure where Groups would fit in.  My first instinct is to keep them
>>> in the Realm also, although I'm not 100% sure... time for some mulling I
>>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121115/38f6c7d6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: realm_design2.png
Type: image/png
Size: 32808 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/security-dev/attachments/20121115/38f6c7d6/attachment-0001.png