[keycloak-dev] user groups vs. client groups
Stan Silvert
ssilvert at redhat.com
Fri Nov 6 08:27:03 EST 2015
On 11/6/2015 7:52 AM, Stian Thorgersen wrote:
> I disagree. Firstly we're not adding Permissions now. Secondly the
> Group is either part of the Subject or it's the equivalent of a Role,
> that depends on policies (which are SE), not the mapping of
> Permissions to the Subject.
We have a completely different idea of what a Group is. That's OK. At
least we are finally using the same vocabulary.
For the sake of this discussion, does it matter that we're not adding
Permissions now? We are planning this, right?
There are several implementations of NIST RBAC out there. I wonder if
there is a good open source one we could just plug in.
>
> Following your argument if you had allowed assigning permissions based
> on dob then the dob of a user would be an SE.
>
> On 6 November 2015 at 13:31, Stan Silvert <ssilvert at redhat.com
> <mailto:ssilvert at redhat.com>> wrote:
>
> 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/20507134/attachment-0001.html
More information about the keycloak-dev
mailing list