[keycloak-dev] user groups vs. client groups

[Stan Silvert]

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
> 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/6a23cc64/attachment-0001.html