[keycloak-dev] Groups design

[Bill Burke]

On 8/20/2015 7:18 PM, Scott Rehorn wrote:
> We've been watching the groups discussion with interest over the last week or so, and we have a some comments and input re your proposed 'groups' implementation:
>
> * our simple, purpose-built 'organizations' requirements can be readily subsumed by a group. It's possible that an 'organization' construct might still be useful as an organization structure similar in function to the 'client template' at the client level, but we'll see.
>
> * We generally feel that the group construct should have attributes associated with it - i.e., a user who is a member of a group gets attributes added to his token. The example we like best is 'subscriptionId' (with some value associated with it) as an attribute associated with a group so that a user identified as a member of that group always has that name-value pair in his token. We consider this an important means to support cooperating clients.
>

Stian didn't like the idea of associating mappers with Groups.   Because 
of this, e're gonna end up having to add conditionals to mappers, i.e. 
if user has role or group, add this attribute.  If user has this 
attribute with value x, add this role or attribute, etc...



> * In our discussions, we tend to believe that 'permissions' are separate from 'roles', but it's not a deal-killer. That is, a role is a collection of permissions, but you can arrive at the same thing by naming convention in roles, e.g., admin-can-perform-backup, admin-can-reboot, etc. The usual treatments of role-based access control separate permissions from roles but that might be a function of academic purity.
>

I always thought a role was just a tag and permissions were something 
that can have value.  i.e. a file permission might be 775.


> * +1 for client templates: this seems like a very helpful construct for organizing configuration patterns (for protocol, IdPs, etc.). Generally the 'client template' seems like a good location to specify a consistent group assignment based on incoming IdP. E.g., a CT could specify that for client x, any user who logs in with one of the available IdPs for that client, automatically gets put into x-users-group. The term 'membership' seems good here: membership defines the group(s) that a given user should belong to as part of client-x.
>

Nah, wouldn't work that way.  You'd define a mapper at the IDP 
Federation entry.  For external IDP X, add mapper Y which assigns user 
to group Z.

> * We think the distinction could be emphasized that groups can be only users and/or other groups and are thus for organizational applications and distinct from roles/permissions. If people make nested groups with conflicting role assignments, that could be trouble, but IMO indicates a larger authZ definition issue that KC shouldn't be involved in.
>
> * The "RoleGroup" concept seems strained, and/or we don't understand the use case. Firstly, using the word 'group' in there is dangerous :). If it's just 'namespace' for roles, then maybe just simple tagging for Roles would be sufficient as a means to collect related roles? Or attach that association in the client template?
>

Role Groups are just a namespace.  You have a good point.  Now that we 
have mappers we kinda don't need role groups.  The counter point is how 
do we migrate older apps?

The counter point is that it becomes harder to pick and choose roles to 
assign/map/whatever if they are not categorized at all.  I'm open to a 
better name than Role Group.

> * You mention that having the URI for a role name is awkward, and, true, it can be a pain, but it's worth noting that it can be a 'urn:' which doesn't need to include a deployment-host-based DNS-based name. A URN is a clean way to express a canonical easily-read identifier (as opposed to a guid or something).
>
> * When you say 'deprecate {default,composite} roles' you just mean that a user's collection of roles is no longer named that way? It's still important for a user to wind up with a collection of roles which are certainly composites (due to possible role assertions contributed by an IdP, or as a result of group membership).
>

Default roles are roles assigned automatically when a user registers or 
when a user is imported from an external IDP.

Right now any role can be a composite of other roles.   Meaning it can 
be associated with other roles.  It is kind of like a group.

We're deprecating both these features in

> * Just to see if we understand the boundaries and responsibilities for mappers:
>    - Claims arriving from an IdP can be mapped to the token, relabeling them
>    - Group and role assignments are mapped into the token for an authenticated user
>    - These mapper configs are governed by client implementers (for better or worse) and implemented as client template directives
>

yeah, I think that would be the initial route.  I'm not sure yet if I 
want to allow clients to override the template they are associated with. 
  Might get messy.


> * Task for The Intern Riding a Unicorn: have a debug UX which creates and displays a token in the admin interface so one could fiddle with the mappers and group assignments without having to write an external client to see the resulting token :)
>

That's a good idea.  Probably not very hard to do either.

> * We think it's implicit, but just to be sure: the group membership collection will also be in the token, correct? So a token has group membership, role association, any claims mapped from the IdP, group-defined attributes, and user-level attributes.
>

Yeah, I think that should be the default.  The default Client Template 
will have some default mappers that adds all user attributes, group 
attributes and group membership.  Then you can remove these defaults as 
needed and bring stuff in a la carte if you want.


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