After our chat I realized I was confusing things. I think the initial design proposed by Bill is good, but we should keep composite roles. Roles should rename roles and we should introduce role namespaces to replace the current realm/client role split. So we should have:
* Role
* Composite role - these are powerful as they permit multiple inheritance (and we also deal with cyclic inheritance). I believe these works well and we've not had any negative feedback on them AFAIK
* Role namespaces - ability to create a hierarchy of roles (a role namespace should just be a namespace, and not some sort of all inclusive role)
* Group
- Simple hierarchy (no multi inheritance)
- A group has one or more attributes
- A group has one or more role mappings
- A user belongs to one or more groups
- A user inherits all role mappings of the group
- A user inherits all attributes of the group (we need to define how duplicates are resolved)
I think this will provide the required tools to model most things. Obviously it doesn't model permissions, but that's not the agenda. Permissions are for Pedro's work, which will hopefully be brought into master sometime next year.
With regards to how this is all added to tokens and managed in adapters we need to be able to:
* Include/exclude groups in the token
* Include/exclude roles in the token
- Including ability to specify namespaces to include
* For JEE adapters it should be possible to configure how roles from the token are mapped onto roles in the app
- Full namespace
- Include single namespace and only include role name, not full namespace
- More (groups -> roles?)? Custom?
Another related topic is fine-grained permissions in the admin console/endpoints. We should leave it as is for now (course grained), with the exception of utilizing role namespaces (instead of having to have "mock" clients). In the future we should be able to leverage Pedro's work to provide proper fine-grained permissions to the admin console/endpoints.