[keycloak-dev] user group admins

[Stian Thorgersen]

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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151105/8fbc16db/attachment.html