<div dir="ltr">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:<div><br></div><div>* Role</div><div>* 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</div><div>* 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)</div><div>* Group</div><div> - Simple hierarchy (no multi inheritance)</div><div> - A group has one or more attributes<br></div><div> - A group has one or more role mappings</div><div><div> - A user belongs to one or more groups</div></div><div> - A user inherits all role mappings of the group</div><div> - A user inherits all attributes of the group (we need to define how duplicates are resolved)</div><div><br></div><div>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.</div><div><br></div><div>With regards to how this is all added to tokens and managed in adapters we need to be able to:</div><div><br></div><div>* Include/exclude groups in the token</div><div>* Include/exclude roles in the token</div><div> - Including ability to specify namespaces to include</div><div>* For JEE adapters it should be possible to configure how roles from the token are mapped onto roles in the app</div><div> - Full namespace</div><div> - Include single namespace and only include role name, not full namespace</div><div> - More (groups -> roles?)? Custom?</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 4 November 2015 at 18:24, Stan Silvert <span dir="ltr"><<a href="mailto:ssilvert@redhat.com" target="_blank">ssilvert@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 11/4/2015 11:51 AM, Bill Burke wrote:<br>
><br>
> On 11/4/2015 11:21 AM, Stan Silvert wrote:<br>
>> On 11/4/2015 10:37 AM, Bill Burke wrote:<br>
>>> On 11/4/2015 10:26 AM, Stan Silvert wrote:<br>
>>>> On 11/4/2015 9:15 AM, Bill Burke wrote:<br>
>>>>> I've alread stated the reason for composite roles:<br>
>>>>><br>
>>>>> Say you have a set of applications under the Sales and Marketing<br>
>>>>> Department: A Leads Application, Eloqua, and Salesforce. Each of the<br>
>>>>> applications has a set of roles that are used to manage access to<br>
>>>>> various features of each application. For example, each app might have<br>
>>>>> an "admin" role. You would then want to organize permissions into<br>
>>>>> categories and assign coarser grain roles to individual users. So, you<br>
>>>>> would create a "Sales Admin" composite role that contains the "admin"<br>
>>>>> role of each sales application. Composite roles allow you to group<br>
>>>>> together roles into role catagories that you can assign to a specific<br>
>>>>> user or user group.<br>
>>>>><br>
>>>>> User Groups are different as you want to assign a set of permissions to<br>
>>>>> a group of users.<br>
>>>>><br>
>>>>> So composite roles are used to group together roles of a set of<br>
>>>>> applications. User Groups are used to grant a set of perissions to a<br>
>>>>> set of users.<br>
>>>> Maybe it's just me, but I think of user groups as just a way to group<br>
>>>> users, and roles as a way to group permissions. Roles are assigned to<br>
>>>> user groups. Permissions are assigned to roles.<br>
>>>><br>
>>> We dont' have the concept of a permission, so, assigning roles to a<br>
>>> composite role is equivalent right now of assigning permissions to a role.<br>
>> Isn't that what Pedro is working on right now?<br>
> No. His is like: user in this group as write access to this document.<br>
> This is just roles and sets of roles.<br>
><br>
><br>
</div></div>"write access to this document" is a permission. Permissions assigned<br>
to roles. Roles assigned to groups.<br>
<br>
Maybe it's just semantics, but that's the kind of think I'm used to<br>
seeing in other systems.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div>