----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 12 August, 2015 3:50:21 PM
Subject: [keycloak-dev] Groups design
I would like to nail down what we want Groups to look like in Keycloak.
And also propose a separate RoleGroups structure.
GROUPS:
* Groups have an id, name, and description
* Groups have an arbitrary set of name/value pair attributes
* Realm/Client roles can be associated with a Group. This is like a
UserRoleMapping, except it is a GroupRoleMapping.
With this concept we don't need composite roles and should remove them.
* Groups can be members of one or more groups
* Users can be members of one or more groups
* Users inherit attributes of the groups they belong to.
* UserModel now has a getGroups(), hasGroup(), grantGroup(), deleteGroup()
* Similar to default roles, we also have default groups.
If we add default groups we don't need default roles and should remove them.
Features we probably want:
* Groups can have a set of protocol Mappers organized by protocol.
* Clients inherit protocol Mappers from the groups a user belongs to.
I'm not sure groups should be the way to "share" protocol mappers. It would
be better to have realm level "protocol mapper definitions" that can be re-used
in clients. What you are suggesting raises a lot of questions:
* What happens when a user belongs to multiple groups that all have protocol mappers
associated. Seems like it would be very unclear in this case what the token would actually
look like. Especially if different groups have conflicting mappings (for example one maps
first-name to name and another maps first+last name to name.
* Shouldn't token format be defined by a client, not by groups? A client will expect a
token is a certain format, but if it's dependent on what group a user belongs to all
bets is off.
Questions:
* Do we want to expand the concept of a Group so that clients and
identity brokers can belong to a Group? Or just create a separate
composite structure for this?
Not sure we need that at all. Can't identity brokers and clients just use mappings to
achieve the required effect? Or am I confusing what effect this would have.
ROLEGROUPS:
RoleGroups are just a namespace for Roles. I want to remove the concept
of realm level and client level roles and just have the concept of a
RoleGroup. The reasoning for this is that I've seen people ask for it.
They want to share a set of roles between clients and realm-level
roles might end up having name clashes, if you are following me.
+100000000000 I've wanted this from the start ;)
* RoleGroups have an id, name and description.
* RoleGroups define a set of roles.
* Users are *NOT* members of RoleGroups
* For migration, a "realm" RoleGroup is created. a RoleGroup for each
client that has defined roles is created. The name will be the clientId
of the client.
* I want to deprecate the "use-resource-role-mappings" switch in the
adapter.
* I want to deprecate the JWT extension we made for roles and have
something completely flat (like SAML) with a URI that identifies each
role (like in UMA spec).
Would that be added to the scope field? Or something else? Scope allows clients to request
what goes into a token and there's a set of standard things we need to support to
achieve OIDC compliance.
How about JEE? It and other framework generally except simple names for roles. We could
make it configurable with the following options (assuming the roles
role://acme.org/role-group-a/role-a,
role://acme.org/role-group-b/role-b):
* Full - roles would be the full uris (
role://acme.org/role-group-a/role-a,
role://acme.org/role-group-b/role-b)
* Simple - specify the "role-group" uri and only roles in that group are
included (if set to
role://acme.org/role-group-a the roles are
role://acme.org/role-group-a/role-a)
* Stripped - includes roles that have a set prefix and removes the prefix (if set to
role://acme.org/ the roles are role-group-a/role-a and role-group-b/role-b)
* We will remove these deprecated features in the final cut of
community
that we fork to move into product.
--
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