12:46 a.m.
On 5 November 2015 at 22:51, Bill Burke <bburke(a)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