Re: [keycloak-dev] roles vs. groups

Stian and I were having a conversation about roles, keycloak composite roles, vs. groups. It seems that groups and roles are often confused and one can be equivalent to the other. One common thread is the following: Groups are user centric. Roles are permission centric. "A group is a means of organising users, whereas a role is usually a means of organising rights." So, keycloak composite roles would be a way to organise rights for a set of applications. For example, you might have a set of sales services, each sales service has an "admin" and "user" role. You'd define a "sales user" and "sales admin" role which would be a composite containing the "admin" and/or "user" role of each sales service. Conversely, a keycloak group would provide a way to organize a set of users. You would create a group called "sales associates" add members to it and then assign the roles members of the group can partake. Really, in Keycloak with composite roles, you can have a role act as a group. So, while groups and roles are logically the sameAdding the concept of a group though provides distinction and clarity without overloading the concept of a composite. So, given that, Role mapping tab for Groups and Users would be named "Permissions" instead of "Role Mappings". Each role would have a "Rights" tab instead of the "Composite Role" concept we have now. That might bring more clarity? Or will it just confuse concepts that are going to be introduced by Pedro and his Authz stuff? I'm also thinking that a Groups and Role Namespaces could be combined. So a group would have a set of "Permissions" (role mappings) that are automatically granted to user members. The group could also define a set of "Roles" that apply to this group. So "Sales" could have a "Manager" role. This "Manager" role would be a composite role that assigns additional permissions. This would also allow us to define default roles for