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