Re: [keycloak-dev] user groups vs. client groups

On 5 November 2015 at 21:40, Stan Silvert <ssilvert(a)redhat.com <mailto:ssilvert@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.

> > 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(a)redhat.com > <mailto:ssilvert@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(a)redhat.com >> <mailto:bburke@redhat.com>> wrote: >> >> >> >> On 11/5/2015 6:23 AM, Stian Thorgersen wrote: >> >> >> >> On 3 November 2015 at 22:20, Bill Burke >> <bburke(a)redhat.com <mailto:bburke@redhat.com> >> <mailto:bburke@redhat.com >> <mailto:bburke@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > >