On 5 November 2015 at 22:51, Bill Burke <bburke@redhat.com> wrote:

On 11/5/2015 1:53 PM, Stian Thorgersen wrote:

As I said in my previous email I think this is overusing and confusing
the concept of a group.

I don't think it is confusing, but it may be overloading the concept of a group.

Users should be able use groups freely for their organizations without
it conflicting with groups Keycloak uses to define permissions.

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:

org.keycloak/<organization>/view-clients
org.keycloak/<organization>/manage-clients
...

An organization is just a namespace for roles and clients? As well as a subset of realm users?

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.

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".

With separate role namespaces you have no clear idea what roles are important to which clients and users.

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.

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.

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:

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?

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:

* An option on a realm that permits admins in it to create new realms

* 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

However, I'm not sure if it's a big deal that an admin has to login to the individual realms to manage them.

* <realm>/admin
* <realm>/protocols
* <realm>/...

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.

Our URLs at the moment are prefixed with '/realms', then there's the two separate URLs for admin endpoints.

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...

--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com