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

[David M. Lloyd]

The ASP/ISP use case might have a valid use for groups; for example, 
consider a case where a user might have different service tiers. 
Mapping tiers to groups seems like a natural way to approach the problem.

On 11/14/2012 03:26 PM, 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
>


-- 
- DML