<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 3 November 2015 at 22:20, 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">In my previous email I talked about combining Groups and Role<br>
Namespaces. Now I want to talk about User Groups vs. Client Groups.<br>
<br>
User Groups would manage a set of users. Members would automatically<br>
inherit a set of "permissions": a set of roles. User Groups would also<br>
provide a set of attributes that the user inherits.<br></blockquote><div><br></div><div>Permission != role</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'd like to introduce the concept of a Client Group. Client Group would<br>
have:<br>
<br>
* Roles - basically a role namespace<br></blockquote><div><br></div><div>-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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Permissions - set of roles service accounts members inherit<br></blockquote><div><br></div><div>-1 It shouldn't be called permissions, it would be role mappings. In either case a service account is backed by a regular user, which can be part of a user group and would get role mappings from there.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Scope - same as our current concept of scope </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Protocol Policies - common protocol configuration.<br></blockquote><div><br></div><div>+1 To scope and protocol policies</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Each Client Group would have some default roles defined. i.e. roles<br>
that allow a user to edit any client in the client group.<br></blockquote><div><br></div><div>I don't understand this</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Each Client would have the same configuration options. They would be<br>
able to have an additional set of roles, permissions, scope, and<br>
overridable Protocol Policies. </blockquote><div><br></div><div>Same comment as above - why would a client have roles/permissions? I assume we where moving away from that with role namespaces</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><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></div>