<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 5 November 2015 at 22:51, 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 1:53 PM, Stian Thorgersen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As I said in my previous email I think this is overusing and confusing<br>
the concept of a group.<br>
<br>
</blockquote>
<br></span>
I don't think it is confusing, but it may be overloading the concept of a group.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Users should be able use groups freely for their organizations without<br>
it conflicting with groups Keycloak uses to define permissions.<br>
<br>
As I proposed we could introduce the concept of an organization/domain.<br>
An admin would then have one or more roles associated with an domain.<br>
The organization/domain would simply be a namespace within the Keycloak<br>
namespace:<br>
<br>
org.keycloak/<organization>/view-clients<br>
org.keycloak/<organization>/manage-clients<br>
...<br>
<br>
</blockquote>
<br></span>
An organization is just a namespace for roles and clients? As well as a subset of realm users?<br>
<br>
I like clients to be able to have their own role namespace as you have a very clear definition of how the client is defined. This client lives at this URL, has these mappers, and publishes/provides these roles and permissions.<br>
<br>
Same for User Groups: This "User Group" has a set of default permissions. As well as a defined set of roles. An "employee" or "manager" in "Accounting" would have different permissions than a "employee" or "manager" within "Engineering".<br>
<br>
With separate role namespaces you have no clear idea what roles are important to which clients and users.</blockquote><div><br></div><div>As I said some use organizational wide roles, others have roles specific to a client or a group of clients. What you are proposing only works with those that have roles specific to a client. Namespaces works for both.</div><div><br></div><div>I disagree that it's a big problem with separate role namespaces as users can easily define sensible namespaces that ties a group of clients to a namespace. We could even have a role namespace attribute on a client group.</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">
One issue with changing "permissions" on the admin endpoints is that<br>
currently we have a duplicated set of these as the master realm and each<br>
individual realm can have these. This is error prone, insecure and just<br>
outright confusing IMO. We should get rid of the master realm and simply<br>
have the admin endpoints and console hosted under a specific realm. This<br>
would also simplify the URLs for other things. So the URLs become:<br>
<br>
</blockquote>
<br></span>
Without a master realm, you have to figure out the chicken and egg problem. How do you create a new realm? How do you manage that new realm? How can you manage more than one realm with one login? Red Hat IT has a need for two separate realms. One for employees and one for customers. Will they have to have two separate admin accounts on each realm to manage them?</blockquote><div><br></div><div>Yes, we do need to figure that out - but I don't think it's a problem and I'm confident we can find a decent solution to it. We could probably implement it so that we'd still have the same realm drop-down in the admin console. Permissions would be done something along the lines off:</div><div><br></div><div>* An option on a realm that permits admins in it to create new realms</div><div>* Use identity brokering to provide SSO to manage other realms - this could be an idp that's hidden and can only be used through the idp_hint</div><div><br></div><div>However, I'm not sure if it's a big deal that an admin has to login to the individual realms to manage them.</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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* <realm>/admin<br>
* <realm>/protocols<br>
* <realm>/...<br>
<br>
</blockquote>
<br></span>
Our URL scheme is already like this. You can log into a specific admin console for a specific realm. The "issue" (depending on your perspective) is that the admin REST interface allows you to interact with any realm.</blockquote><div><br></div><div>Our URLs at the moment are prefixed with '/realms', then there's the two separate URLs for admin endpoints.</div><div><br></div><div>Several users has been confused about the admin client libraries where you login with one realm and manage another. I still get confused when dealing with the admin endpoints and dealing with permissions. What is the master realm client, what is the non-master realm client, etc...</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>