3:44 p.m.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>