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.
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?
* <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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com