11:31 a.m.
A few users have been asking about the ability to limit the admin to
managing a set of users in a group.
I know Pedro is doing permission work, but IMO, this type of thing needs
to be integrated and natural to the Keycloak UI as it would be a
fundamental feature.
Here's a proposal though based on my layout of User Groups in a previous
email.
Group Admins need to be able to:
* Manage group membership
* Manage users within a group to do things like reset credentials and
other user management actions.
* Grant roles to users within a group
* Add attributes to the group
* Grant roles to the group
So, if each User Group had its own Role Namespace, we could define one
or more roles that grant each of those permissions. i.e.
"group-membership-admin", "group-user-admin", "group-admin".
If a User
Gruop has its own Role Namespace, it becomes really easy to compose
adminstrative access. So you could define individual "admin groups" and
grant users in those groups permission to manage one more groups.
If groups don't have their own Role Namespace, you need a way to
associate a role to each group admin permission.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
12:53 p.m.
As I said in my previous email I think this is overusing and confusing 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
...
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:
* <realm>/admin
* <realm>/protocols
* <realm>/...
On 5 November 2015 at 18:31, Bill Burke <bburke(a)redhat.com> wrote:
A few users have been asking about the ability to limit the admin to
managing a set of users in a group.
I know Pedro is doing permission work, but IMO, this type of thing needs
to be integrated and natural to the Keycloak UI as it would be a
fundamental feature.
Here's a proposal though based on my layout of User Groups in a previous
email.
Group Admins need to be able to:
* Manage group membership
* Manage users within a group to do things like reset credentials and
other user management actions.
* Grant roles to users within a group
* Add attributes to the group
* Grant roles to the group
So, if each User Group had its own Role Namespace, we could define one
or more roles that grant each of those permissions. i.e.
"group-membership-admin", "group-user-admin",
"group-admin". If a User
Gruop has its own Role Namespace, it becomes really easy to compose
adminstrative access. So you could define individual "admin groups" and
grant users in those groups permission to manage one more groups.
If groups don't have their own Role Namespace, you need a way to
associate a role to each group admin permission.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3:51 p.m.
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
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
3659
days inactive
3660
days old
3 comments
2 participants
participants (2)
-
Bill Burke -
Stian Thorgersen