[keycloak-dev] user group admins

[Stian Thorgersen]

On 5 November 2015 at 22:51, Bill Burke <bburke at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151106/36e4a9f3/attachment-0001.html