[keycloak-dev] user groups vs. client groups
Stan Silvert
ssilvert at redhat.com
Fri Nov 6 07:31:37 EST 2015
On 11/6/2015 1:48 AM, Stian Thorgersen wrote:
>
>
> On 5 November 2015 at 21:40, Stan Silvert <ssilvert at redhat.com
> <mailto:ssilvert at redhat.com>> wrote:
>
> 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.
>
>
> Group is not SE, I'm pretty sure of that. A group is just an
> "attribute" of the subject. It doesn't "provide" any permissions or
> any mapping between subjects and permissions.
Let's say you allow Permissions and Roles to be assigned to a Group.
And you also design it such that any Subject who becomes a member of the
group also gets the assigned Permissions and Roles. In that case, you
have implemented a Group that acts as the SE.
>
>
>>
>> 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/20151106/3c46df15/attachment-0001.html
More information about the keycloak-dev
mailing list