[keycloak-dev] user groups vs. client groups

Stan Silvert ssilvert at redhat.com
Thu Nov 5 15:40:42 EST 2015


On 11/5/2015 2:36 PM, Stian Thorgersen wrote:
> We're only providing parts of RBAC now. The complete picture is what 
> Pedro is working on with his AuthZ service.
Yea, as I understand it, Pedro is doing P.  (P for Pedro!)  And also, 
he's filling in the rest of the gaps surrounding P.
>
> From the definitions above we're actually only providing S and R. SE 
> is not a group as a group doesn't provide any permissions.
Maybe that's a good reason to stick with the definitions below.  I see 
"Group" as a way to implement the mapping called for in SE.  But it 
doesn't have to be that way.
>
> I'm not 100% sure what the group would be in the above, but I would 
> think it's just part of S. A group is simply a means of assigning a 
> role to a group of users.
>
>
> On 5 November 2015 at 20:24, Stan Silvert <ssilvert at redhat.com 
> <mailto:ssilvert at redhat.com>> wrote:
>
>     We could do a lot worse than just following the basic RBAC design
>     described on Wikipedia:
>     https://en.wikipedia.org/wiki/Role-based_access_control
>
>     Right now we're arguing over both definitions AND
>     implementations.  It's impossible to design this over email if we
>     can't even settle on definitions.
>
>     Therefore, I propose we just use the definitions in wikipedia.  At
>     least it's neutral.
>
>       * S = Subject = A person or automated agent
>       * R = Role = Job function or title which defines an authority level
>       * P = Permissions = An approval of a mode of access to a resource
>       * SE = Session = A mapping involving S, R and/or P
>       * SA = Subject Assignment
>       * PA = Permission Assignment
>       * RH = Partially ordered Role Hierarchy. RH can also be written:
>         ≥ (The notation: x ≥ y means that x inherits the permissions
>         of y.)
>           o A subject can have multiple roles.
>           o A role can have multiple subjects.
>           o A role can have many permissions.
>           o A permission can be assigned to many roles.
>           o An operation can be assigned many permissions.
>           o A permission can be assigned to many operations.
>
>
>     Note: In my mind, S = keycloak user, and SE = keycloak group.  But
>     whatever, as long as we agree on definitions we can then decide
>     what flavor of RBAC to implement.
>
>
>     On 11/5/2015 1:44 PM, Stian Thorgersen wrote:
>>
>>
>>     On 5 November 2015 at 15:01, Bill Burke <bburke at redhat.com
>>     <mailto:bburke at redhat.com>> wrote:
>>
>>
>>
>>         On 11/5/2015 6:23 AM, Stian Thorgersen wrote:
>>
>>
>>
>>             On 3 November 2015 at 22:20, Bill Burke
>>             <bburke at redhat.com <mailto:bburke at redhat.com>
>>             <mailto:bburke at redhat.com <mailto:bburke at redhat.com>>> wrote:
>>
>>                 In my previous email I talked about combining Groups
>>             and Role
>>                 Namespaces.  Now I want to talk about User Groups vs.
>>             Client Groups.
>>
>>                 User Groups would manage a set of users.  Members
>>             would automatically
>>                 inherit a set of "permissions": a set of roles.  User
>>             Groups would also
>>                 provide a set of attributes that the user inherits.
>>
>>
>>             Permission != role
>>
>>
>>                 I'd like to introduce the concept of a Client Group. 
>>             Client Group would
>>                 have:
>>
>>                 * Roles - basically a role namespace
>>
>>
>>             -1 Having roles tied to a client or client group is
>>             exactly what we
>>             should go away from. IMO role namespaces should be a
>>             completely separate
>>             thing.
>>
>>
>>         I don't agree at all.  If User Groups and Client Groups
>>         exist, there is no need for role namespaces.  It is stupid to
>>         have to create another concept (role namespace) to define the
>>         roles one specific client or a group of clients expects.
>>
>>
>>     I've never the concept of realm and client roles. It's been
>>     difficult to explain and strange to use. I've always just used
>>     realm roles. It's a strange and limiting concept. Introducing
>>     client groups with further places to define roles just makes
>>     matters even worse. Now users have two go 3 different places to
>>     define roles:
>>
>>     * Realm
>>     * Client Groups
>>     * Clients
>>
>>     What happens if a client group and a client both have the same
>>     role by the way?
>>
>>     It's a strange limitation. At least personally if I was using
>>     Keycloak I would simply use realm roles alone and define my own
>>     hierarchy with a delimiter.
>>
>>     It's much better to have a single place to define roles, under
>>     the roles tab. Then allow users can define the
>>     namespaces/hierarchy they want.
>>
>>     Role namespaces are easier to deal with and at the same time more
>>     flexible.
>>
>>     I just don't see any reason why we would have roles specific to a
>>     client or client group.
>>
>>
>>         If you combine Role namespace and Groups you can define
>>         things like a group admin role. Roles that mean something to
>>         the group.
>>
>>
>>                 Each Client Group would have some default roles
>>             defined.  i.e. roles
>>                 that allow a user to edit any client in the client group.
>>
>>
>>             I don't understand this
>>
>>
>>         A Client Group could have a "client group admin" role.  If a
>>         user has that role it can manage clients in the group. 
>>         Another role might be "client membership admin". This role
>>         allows a user to add or remove clients from the group.
>>
>>         Conversely, user groups could have a "user group admin". 
>>         When granted, this role allows a user to manage users in the
>>         group. YOu can also do things like define a "Manager" role
>>         for the group.  This "Manager" would be granted "user group
>>         admin" privileges and also granted access to other systems
>>         like "HR", "Attendence", "Benefits", etc.
>>
>>         I think this permission concept should be built into Keycloak
>>         as it is a core feature.  I'll write u a separate email about
>>         this.
>>
>>
>>     This is another reason why we need role namespaces. With a role
>>     namespace we can define internal roles that then don't end up
>>     conflicting with users own roles. For example as we have a role
>>     admin atm users can't define their own admin role and will have
>>     to name it differently.
>>
>>     I think the fact that we have internal abstract clients to be
>>     able to create a namespace for internal admin roles speaks for
>>     itself.
>>
>>
>>
>>
>>
>>                 Each Client would have the same configuration
>>             options.  They would be
>>                 able to have an additional set of roles, permissions,
>>             scope, and
>>                 overridable Protocol Policies.
>>
>>
>>             Same comment as above - why would a client have
>>             roles/permissions? I
>>             assume we where moving away from that with role namespaces
>>
>>
>>         Again, I think role namespaces are redundant.
>>
>>         A client can define a set of roles that it offers.  A service
>>         account (the client) can have roles associated with it so it
>>         can do certain actions.
>>
>>
>>     Some will want to have roles associated with a client
>>     (email-user), but others have organizational wide roles (manager,
>>     sales-guy, etc..). Role namespaces can deal with both, but client
>>     roles can't.
>>
>>
>>
>>
>>
>>         -- 
>>         Bill Burke
>>         JBoss, a division of Red Hat
>>         http://bill.burkecentral.com
>>
>>
>>
>>
>>     _______________________________________________
>>     keycloak-dev mailing list
>>     keycloak-dev at lists.jboss.org  <mailto:keycloak-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151105/7f5c9747/attachment-0001.html 


More information about the keycloak-dev mailing list