<div dir="ltr">As I said in my previous email I think this is overusing and confusing the concept of a group.<div><br></div><div>Users should be able use groups freely for their organizations without it conflicting with groups Keycloak uses to define permissions.</div><div><br></div><div>As I proposed we could introduce the concept of an organization/domain. An admin would then have one or more roles associated with an domain. The organization/domain would simply be a namespace within the Keycloak namespace:</div><div><br></div><div>org.keycloak/<organization>/view-clients</div><div>org.keycloak/<organization>/manage-clients<br></div><div>...</div><div><br></div><div>One issue with changing "permissions" on the admin endpoints is that currently we have a duplicated set of these as the master realm and each individual realm can have these. This is error prone, insecure and just outright confusing IMO. We should get rid of the master realm and simply have the admin endpoints and console hosted under a specific realm. This would also simplify the URLs for other things. So the URLs become:</div><div><br></div><div>* <realm>/admin</div><div>* <realm>/protocols</div><div>* <realm>/... </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 5 November 2015 at 18:31, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A few users have been asking about the ability to limit the admin to<br>
managing a set of users in a group.<br>
<br>
I know Pedro is doing permission work, but IMO, this type of thing needs<br>
to be integrated and natural to the Keycloak UI as it would be a<br>
fundamental feature.<br>
<br>
Here's a proposal though based on my layout of User Groups in a previous<br>
email.<br>
<br>
Group Admins need to be able to:<br>
* Manage group membership<br>
* Manage users within a group to do things like reset credentials and<br>
other user management actions.<br>
* Grant roles to users within a group<br>
* Add attributes to the group<br>
* Grant roles to the group<br>
<br>
So, if each User Group had its own Role Namespace, we could define one<br>
or more roles that grant each of those permissions. i.e.<br>
"group-membership-admin", "group-user-admin", "group-admin". If a User<br>
Gruop has its own Role Namespace, it becomes really easy to compose<br>
adminstrative access. So you could define individual "admin groups" and<br>
grant users in those groups permission to manage one more groups.<br>
<br>
If groups don't have their own Role Namespace, you need a way to<br>
associate a role to each group admin permission.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<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>
</font></span></blockquote></div><br></div>