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.
* 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.
* +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.
* 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?
* 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).
* 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
* 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 :)
* 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.
- scott r
(On behalf of the identity broker team at Dell Software)
-----Original Message-----
From: keycloak-dev-bounces(a)lists.jboss.org [mailto:keycloak-dev-
bounces(a)lists.jboss.org] On Behalf Of Stian Thorgersen
Sent: Wednesday, August 19, 2015 11:50 PM
To: Bill Burke <bburke(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Subject: Re: [keycloak-dev] Groups design
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Thursday, 20 August, 2015 3:53:28 AM
> Subject: Re: [keycloak-dev] Groups design
>
>
>
> On 8/19/2015 3:17 AM, Stian Thorgersen wrote:
> >>> Have the concept of Role Groups:
> >>> * Role Groups are just a namespace for roles.
> >
> > Just to double check as part of this we're removing the concept of
> > realm and client roles, and we're also adding some ability of
> > defining what roles are listed in adapters (so we can have plain
> > role names, like 'user', in jee apps for example)
> >
>
> Yes. We'll have a flat user role mapping in the token
>
> roles: [ "role1", "role2" ]
>
> You'll either manipulate how roles look in the token via a mapper, or
> you'll define a role mapping within the adapter config. Default role
> mapper on server will specify a URI for the role. BTW, this URI
> probably shouldn't have a DNS name within it. Something like
> role:{realm-name}.{group}.{role-name}. This is so that adapter config
> doesn't have to be changed as it moves from dev->QE->production. BTW,
> this is why I hate the OIDC requirement that the realm is some http://
> based URI.
Do we need real-name? Seems like that'll only make it hard to use.
I like OIDC requirement that it's URL based - a realm is not a unique name,
but a URL is and I think it should be unique
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev