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

From the definitions above we're actually only providing S and R. SE is not

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.) - A subject can have multiple roles. - A role can have multiple subjects. - A role can have many permissions. - A permission can be assigned to many roles. - An operation can be assigned many permissions. - 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&gt; 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>> 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 listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev