Ok guys, brace yourselves:



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.