[security-dev] IDM Realms, take 3

[Shane Bryzak]

Ok guys, brace yourselves:

Realm/Tier relationships

In this design I've tried to address both David's and Bill's use cases, 
by introducing a hierarchical Tier structure and adding support for 
Tier-specific groups.  Specific constraints I'll describe in the 
following sections:

Users
--------
1. A User is specific to a realm
2. A User may be assigned a group role where both the group and role 
exist either in the realm (i.e. a global group role), or in a tier 
(tier-specific group role)
3. A User may be a member of a group, where the group exists either in 
the realm (i.e. a global group) or in a tier (tier-specific group 
membership)
4. A User may be granted a global role (where the role exists in the 
same realm of the user), or a tier-specific role (where the role exists 
in a tier)

Groups
----------
5. A Group may belong to a realm (i.e. a global Group), or to a tier (a 
tier-specific Group)
6. A Group may be a subgroup of another Group within the same realm or 
the same tier
7. A global Group may be a member of a tier-specific Group, in which 
case all members of the global Group are also treated as members of the 
tier-specific Group
8. A global Group may be granted a global role (where the role exists in 
the same realm of the Group)
9. A global Group may be granted a tier-specific Role
10. A tier-specific Group may be granted a tier-specific Role when the 
Role exists in the same tier of the Group
11. Members of a Group automatically inherit all privileges assigned to 
the Group, and the Group's parent Group

Roles
-------
12. A Role may belong to a realm (i.e. a global Role) or to a tier (a 
tier-specific Role)
13. Privileges granted to a User or Group with a tier-specific Role are 
inherited by the sub-tiers of the Role's tier

I *think* that pretty much describes all constraints of this design.  If 
anyone is interested (or is confused by this), I can follow up on this 
with a bunch of examples to illustrate the constraints in an 
easier-to-digest format.  I'm quite certain that this design should 
address all the use cases described so far, but as always I'd like to 
hear feedback (especially from Bill and David).  Unfortunately this 
means that the stabilization of the IDM API has to be delayed a little 
longer however I believe that it is worth it in the interest of nailing 
down the best design possible before we proceed to code the implementation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20121119/57de4963/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: realm_tier.png
Type: image/png
Size: 53417 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/security-dev/attachments/20121119/57de4963/attachment-0001.png