[security-dev] IDM Realms, take 3

[Bill Burke]

Looks like what you have can work....But...  The SOA/multi-tier model 
I'm prototyping is starting to look a little different, maybe simpler??? 
(I don't know):

User, Realm, Resource, Role, ResourceRoleMapping

Realm->1..N User
Realm->1..N Resource
Resource->1..N Role

ResourceRoleMapping
* realmid
* userid
* resourceid
* String[] roles
* surrogate (userid)

- Surrogate defines a user that is allowed to act on behalf of a 
different user on a particular resource.
- Each Resource is also registered as a user
- A resource is created to represent the realm.  User's are mapped to 
that resource to have admin priviledges within the realm (create 
resources, users, etc...)

This way I don't need hierarchies and/or tiers to illustrate the highly 
distributed use cases I have in mind.

On 11/18/2012 6:17 PM, Shane Bryzak wrote:
> 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.
>
>
>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com