4:10 p.m.
Here's what we want to be able to manage for fine-grain admin
permissions for the 1st iteration. If you think we need more, let me
know, but I want to keep this list as small as possible.
User management
* Admin can only apply certain roles to a user
* Admin can view users of a specific group
* Admin can manage users of a specific group (creds, role mappings, etc)
Group Management
* Admin can only manage a specific group
* Admin can only apply certain roles to a group
* Admin can only manage attributes of a specific group
* Admin can control group membership (add/remove members)
Client management:
* Admin can only manage a specific client.
* Admin can manage only configuration for a specific client and not
scope mappings or mappers. We have this distinction so that rogues
can't expand the scope of the client beyond what it is allowed to.
* Service accounts can manage the configuration of the client by default?
8:37 a.m.
On 21/03/17 22:10, Bill Burke wrote:
Here's what we want to be able to manage for fine-grain admin
permissions for the 1st iteration. If you think we need more, let me
know, but I want to keep this list as small as possible.
User management
* Admin can only apply certain roles to a user
* Admin can view users of a specific group
* Admin can manage users of a specific group (creds, role mappings, etc)
Maybe
also:
* Admin can only apply roles/groups, which he himself has
AFAIK currently we have issues that user with "manage-users" role can
assign any role to himself and hence gain permission to everything.
Group Management
* Admin can only manage a specific group
* Admin can only apply certain roles to a group
* Admin can only manage attributes of a specific group
* Admin can control group membership (add/remove members)
Client management:
* Admin can only manage a specific client.
* Admin can manage only configuration for a specific client and not
scope mappings or mappers. We have this distinction so that rogues
can't expand the scope of the client beyond what it is allowed to.
+1
Especially stuff like hardcoded-role protocol mapper is quite tricky
stuff. If admin can add it to any client, he can retrieve token with
permission to edit anything.
Maybe just some "safe" protocol mapper implementations should be
whitelisted? Or have authorization policy integration to doublecheck
that user is really member of particular role and not just rely on token
roles?
Marek
* Service accounts can manage the configuration of the client by
default?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:15 a.m.
On 3/22/17 9:37 AM, Marek Posolda wrote:
On 21/03/17 22:10, Bill Burke wrote:
> Here's what we want to be able to manage for fine-grain admin
> permissions for the 1st iteration. If you think we need more, let me
> know, but I want to keep this list as small as possible.
>
> User management
>
> * Admin can only apply certain roles to a user
> * Admin can view users of a specific group
> * Admin can manage users of a specific group (creds, role
> mappings, etc)
Maybe also:
* Admin can only apply roles/groups, which he himself has
AFAIK currently we have issues that user with "manage-users" role can
assign any role to himself and hence gain permission to everything.
This falls under the category of "Admin can only apply certain roles to
a user". We're talking implementation detail here, but the way I
envision it will work is each role can define policies on how it is
allowed to be assigned. For example: the "manage-realm" role can only
be assigned if the user has the "admin" role. Also, any policy will be
defined using the Authz service.
Bill
7:52 p.m.
What about
Identity providers
* Admin can only manage a specific identity provider?
On Wed, Mar 22, 2017 at 8:10 AM, Bill Burke <bburke(a)redhat.com> wrote:
Here's what we want to be able to manage for fine-grain admin
permissions for the 1st iteration. If you think we need more, let me
know, but I want to keep this list as small as possible.
User management
* Admin can only apply certain roles to a user
* Admin can view users of a specific group
* Admin can manage users of a specific group (creds, role mappings, etc)
Group Management
* Admin can only manage a specific group
* Admin can only apply certain roles to a group
* Admin can only manage attributes of a specific group
* Admin can control group membership (add/remove members)
Client management:
* Admin can only manage a specific client.
* Admin can manage only configuration for a specific client and not
scope mappings or mappers. We have this distinction so that rogues
can't expand the scope of the client beyond what it is allowed to.
* Service accounts can manage the configuration of the client by default?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
1:24 a.m.
Is that really needed? Managing identity providers is managing realm
configuration. It's also very complicated due to fact that it's importing
users into the realm and the permissions those users receive can also be
configured through mappers.
On 23 March 2017 at 01:52, Dumitru Sbenghe <dsbenghe(a)gmail.com> wrote:
What about
Identity providers
* Admin can only manage a specific identity provider?
On Wed, Mar 22, 2017 at 8:10 AM, Bill Burke <bburke(a)redhat.com> wrote:
> Here's what we want to be able to manage for fine-grain admin
> permissions for the 1st iteration. If you think we need more, let me
> know, but I want to keep this list as small as possible.
>
> User management
>
> * Admin can only apply certain roles to a user
> * Admin can view users of a specific group
> * Admin can manage users of a specific group (creds, role mappings,
etc)
>
> Group Management
>
> * Admin can only manage a specific group
> * Admin can only apply certain roles to a group
> * Admin can only manage attributes of a specific group
> * Admin can control group membership (add/remove members)
>
> Client management:
>
> * Admin can only manage a specific client.
> * Admin can manage only configuration for a specific client and not
> scope mappings or mappers. We have this distinction so that rogues
> can't expand the scope of the client beyond what it is allowed to.
> * Service accounts can manage the configuration of the client by
default?
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
12:54 a.m.
That seems to cover the use-cases I had in mind. I'd also like to highlight
what Marek pointed out around protocol mappers. That was found as one of
the issues with dynamic client registration that we had to tackle.
Basically it could have been used for priviledge escalation through the
client registration services. We solved that by introducing the client
registration policies. Maybe we need different policies applied to
different admins.
How would this be encoded? Rather than having lists of admin can access
this, admin can access that. Would it not be better to have some role or
group where a member of that role/group can access a set of users, a set of
roles, a set of clients, etc..?
On 21 March 2017 at 22:10, Bill Burke <bburke(a)redhat.com> wrote:
Here's what we want to be able to manage for fine-grain admin
permissions for the 1st iteration. If you think we need more, let me
know, but I want to keep this list as small as possible.
User management
* Admin can only apply certain roles to a user
* Admin can view users of a specific group
* Admin can manage users of a specific group (creds, role mappings, etc)
Group Management
* Admin can only manage a specific group
* Admin can only apply certain roles to a group
* Admin can only manage attributes of a specific group
* Admin can control group membership (add/remove members)
Client management:
* Admin can only manage a specific client.
* Admin can manage only configuration for a specific client and not
scope mappings or mappers. We have this distinction so that rogues
can't expand the scope of the client beyond what it is allowed to.
* Service accounts can manage the configuration of the client by default?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
9:02 a.m.
I'm just trying to define the initial operations we want to cover and
how fine grain we might want to go. When I wrote "Admin can" below, I
do not discuss how the admin is defined. I'll get into what default
policies will be later on as I learn the limitations of the Authz
service. I want to implement as you describe, not defining permissions
PER ADMIN, but based on group membership and role mappings of the admin
user.
On 3/23/17 1:54 AM, Stian Thorgersen wrote:
That seems to cover the use-cases I had in mind. I'd also like to
highlight what Marek pointed out around protocol mappers. That was
found as one of the issues with dynamic client registration that we
had to tackle. Basically it could have been used for priviledge
escalation through the client registration services. We solved that by
introducing the client registration policies. Maybe we need different
policies applied to different admins.
How would this be encoded? Rather than having lists of admin can
access this, admin can access that. Would it not be better to have
some role or group where a member of that role/group can access a set
of users, a set of roles, a set of clients, etc..?
On 21 March 2017 at 22:10, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Here's what we want to be able to manage for fine-grain admin
permissions for the 1st iteration. If you think we need more, let me
know, but I want to keep this list as small as possible.
User management
* Admin can only apply certain roles to a user
* Admin can view users of a specific group
* Admin can manage users of a specific group (creds, role
mappings, etc)
Group Management
* Admin can only manage a specific group
* Admin can only apply certain roles to a group
* Admin can only manage attributes of a specific group
* Admin can control group membership (add/remove members)
Client management:
* Admin can only manage a specific client.
* Admin can manage only configuration for a specific client and not
scope mappings or mappers. We have this distinction so that
rogues
can't expand the scope of the client beyond what it is allowed to.
* Service accounts can manage the configuration of the client by
default?
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
3298
days inactive
3300
days old
6 comments
4 participants
participants (4)
-
Bill Burke -
Dumitru Sbenghe -
Marek Posolda -
Stian Thorgersen