[keycloak-dev] Groups design

[Scott Rehorn]

Comments inlineŠ


On 8/20/15, 7:34 PM, "Bill Burke" <bburke at redhat.com> wrote:

>
>
>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...
>

I can see that, but I think what we're talking about is actually dumber.
We want to define the group entity with attributes which come along as
part of the group itself during normal mapping so there is no logic there.
A mapper would inject a group assertion into a token for "AcmeBostonUsers"
and this group definition would carry with it an attribute expressing
"officeLocation=Boston". One *could* do this just with more groups, but it
overloads the purpose of group labels. Mappers can and should be fairly
simple at first, as they are just a mechanism to map claims (with optional
transformation) from some source into the token. Currently there are two
sources for claims, the IdP, and KC itself. BTW we've been doing a bunch
with mappers using drools and it's working well - it gives us a nice
pluggable way to do interesting transformations without having to change
intrinsic KC code.
 

>
>
>> * 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.


That¹s a compact way to view it. In this rbac-stuff, you cannot assign a
permission to a user, you can only assign one or more permissions to a
role, and the role is assigned to the user or group. So to make 'scott' an
admin, then you would create 'AppAdmin' group is assigned the 'Admin'
role. The Admin role carries permissions like 'root-access=false',
'restart=ohhailno' so when scott logs in as part of group AppAdmin, then
he has that role's permissions. Tagged permissions works better for me
mentally because the typical hierarchical model of RBAC can yield weird
and messy combinations of permissions and roles, but a taggy graph would
be simpler.

 

>
>
>> * +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.

Ah ok yes - I was getting overly excited about what could be put in a
client template :) 

>
>> * 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.


Candidates: "RoleCollection" or "RoleNamespace" (the latter makes sense to
me, anyway). Maybe a loose, opt-in tagging mecha would work? I can
definitely see how a proliferation of these things would be a pain. That
is, from the admin console, a user just sees a flat listing of roles to
which he can assign tags and then filter the view by tag?
 

>
>> * 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.

Agreed - override is a maybe-later thing. In our use case, it's important
for a client to be able to read/write values for attributes for users and
groups subject to authZ constraints, and we eventually want to support
what amounts to a schema - validation for values written to an attribute
for a particular client, and the ability for a client to add and manage
new attributes persisted in KC for a given client.



>
>
>> * 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.

Ha, yes, indeed almost fun :)



>
>> * 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

- scott r
(on behalf of the Dell Identity Broker team) at Dell Software Group