<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 November 2015 at 15:01, 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"><span class=""><br>
<br>
On 11/5/2015 6:23 AM, Stian Thorgersen wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On 3 November 2015 at 22:20, Bill Burke <<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a><br></span><span class="">
<mailto:<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>>> wrote:<br>
<br>
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>
<br>
<br>
Permission != role<br>
<br>
<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>
<br>
<br>
-1 Having roles tied to a client or client group is exactly what we<br>
should go away from. IMO role namespaces should be a completely separate<br>
thing.<br>
<br>
</span></blockquote>
<br>
I don't agree at all. If User Groups and Client Groups exist, there is no need for role namespaces. It is stupid to have to create another concept (role namespace) to define the roles one specific client or a group of clients expects.<br></blockquote><div><br></div><div>I've never the concept of realm and client roles. It's been difficult to explain and strange to use. I've always just used realm roles. It's a strange and limiting concept. Introducing client groups with further places to define roles just makes matters even worse. Now users have two go 3 different places to define roles:</div><div><br></div><div>* Realm</div><div>* Client Groups</div><div>* Clients</div><div><br></div><div>What happens if a client group and a client both have the same role by the way?</div><div><br></div><div>It's a strange limitation. At least personally if I was using Keycloak I would simply use realm roles alone and define my own hierarchy with a delimiter.</div><div><br></div><div>It's much better to have a single place to define roles, under the roles tab. Then allow users can define the namespaces/hierarchy they want.</div><div><br></div><div>Role namespaces are easier to deal with and at the same time more flexible. </div><div><br></div><div>I just don't see any reason why we would have roles specific to a client or client group.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If you combine Role namespace and Groups you can define things like a group admin role. Roles that mean something to the group.<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br>
<br>
I don't understand this<br>
<br>
</blockquote>
<br></span>
A Client Group could have a "client group admin" role. If a user has that role it can manage clients in the group. Another role might be "client membership admin". This role allows a user to add or remove clients from the group.<br>
<br>
Conversely, user groups could have a "user group admin". When granted, this role allows a user to manage users in the group. YOu can also do things like define a "Manager" role for the group. This "Manager" would be granted "user group admin" privileges and also granted access to other systems like "HR", "Attendence", "Benefits", etc.<br>
<br>
I think this permission concept should be built into Keycloak as it is a core feature. I'll write u a separate email about this.</blockquote><div><br></div><div>This is another reason why we need role namespaces. With a role namespace we can define internal roles that then don't end up conflicting with users own roles. For example as we have a role admin atm users can't define their own admin role and will have to name it differently.</div><div><br></div><div>I think the fact that we have internal abstract clients to be able to create a namespace for internal admin roles speaks for itself. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
<br>
<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.<br>
<br>
<br>
Same comment as above - why would a client have roles/permissions? I<br>
assume we where moving away from that with role namespaces<br>
<br>
</blockquote>
<br></span>
Again, I think role namespaces are redundant.<br>
<br>
A client can define a set of roles that it offers. A service account (the client) can have roles associated with it so it can do certain actions.</blockquote><div><br></div><div>Some will want to have roles associated with a client (email-user), but others have organizational wide roles (manager, sales-guy, etc..). Role namespaces can deal with both, but client roles can't.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<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>
</div></div></blockquote></div><br></div></div>