[security-dev] IDM Realms and Applications - The Nitty Gritty
sbryzak at redhat.com
Wed Nov 14 16:26:02 EST 2012
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
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
>> 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
>> security-dev mailing list
>> security-dev at lists.jboss.org
More information about the security-dev