[security-dev] IDM Realms, take 3

[Shane Bryzak]

I think it will still work just fine, we possibly have a slight 
misalignment in the definition of terms but this is not really 
significant.  Surrogacy I think can be addressed as a separate issue to 
this design, and the actual authorization side of things (i.e. mapping 
groups, roles and users to actual resource privileges) is already 
addressed comprehensively by the permissions API.  If there's no final 
objections, I'd like to lock down the API based on this design.


On 11/20/2012 02:35 AM, Bill Burke wrote:
> 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
>>