[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