[keycloak-dev] restricted admin console access

[Pedro Igor Silva]

Btw, for the UI part of the discussion I have a simple example. A fairly
simple angular client building a menu with the permissions obtained from
the server.

On Fri, May 12, 2017 at 1:06 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> On Fri, May 12, 2017 at 12:37 PM, Bill Burke <bburke at redhat.com> wrote:
>
>>
>>
>> On 5/12/17 11:05 AM, Pedro Igor Silva wrote:
>>
>> On Fri, May 12, 2017 at 10:40 AM, Bill Burke <bburke at redhat.com> wrote:
>>
>>> I want business as usual for existing deployments.  I don't want people
>>> to have to go and reconfigure existing admins when they want to add a
>>> restricted admin.  Basically we can avoid access token bloat for
>>> old-school admins.  The new console roles will not be added for them.
>>> Only restricted admins using new permission model will have the extra
>>> "console" roles.
>>>
>>> Let's walk through an example of creating a restricted admin that can
>>> only manage users that belong to a specific group.
>>>
>>> 1. Create Group "Sales"
>>>
>>> 2. Turn on fine grain permissions for "Sales" group
>>>
>>> 3. Add policy for "manage-members" for "Sales" group.  Let's say if
>>> restricted admin has "sales-manager" role, they can manage members of
>>> "Sales" group
>>>
>>> 4. Lookup user "bdecoste" who is a sales manager.
>>>
>>> 5. Grant bdecoste "sales-manager" role
>>>
>>> 6. Grant bdecoste "console-access-users" role.
>>>
>>>
>>> Now bdecoste logs into admin console.
>>>
>>> 1. admin console queries permissions endpoint gets back a json doc:
>>>
>>> {
>>>
>>>     "realm-view" : false,
>>>
>>>     "clients-view" : false,
>>>
>>>     "users-view" : true
>>>
>>>     "groups-view" : false
>>>
>>> }
>>>
>>
>> It seems you have created a "permission endpoint" to build this
>> permission json doc. But i'm wondering if can just make the admin console
>> behave like any other client accessing an API protected by our policy
>> enforcers.
>>
>> The idea is that the admin console would basically manage whatever the
>> permissions are within a RPT and send this RPT on every single request. So
>> we would also have the Admin REST API protected.
>>
>> For instance.
>>
>> 1. User logs in.
>> 2. We invoke the Entitlement API to obtain permissions for a specific set
>> of resources that we need to build the UI.
>> 3. We get a RPT with the permissions. Something like that:
>>
>> {
>>     permissions: {
>>         "resource_set_name" : "User",
>>        "scopes": {
>>            "view"
>>        }
>>     }
>> }
>>
>> You made me think awhile if I should do this or not.  I don't think I can
>> use the entitlement service for most things.
>>
>> I do this custom endpoint because Authz may not be initialized yet for
>> the particular resource I"m interested in.  We aren't going to create a
>> Migration script that creates Authz resources for every Group, Role, and
>> Client.  We have deployments of Keycloak that have tens of thousands of
>> Groups and Roles and hundreds of clients.  We also have deployments that
>> may have hundreds of Realms.  We have to be very careful what we do in
>> Migration scripts as we don't want Keycloak to have a 1 hour boot up time
>> as it creates thousands and thousands of new rows in the database.  There
>> also will NEVER be a resource created per-user as this would just not be
>> scalable.  This is why I want the Authz model to be populated as needed,
>> not out of the box.
>>
>> So, if I wanted to use the entitlement service, I really could only use
>> it for what menu items to show on the front page of the admin console.
>> Permissions for individual groups, clients, roles, and users will need a
>> custom REST API as the corresponding Authz datamodel might not be
>> initialized yet.
>>
>
> +1. That is my point. We can use it for building UI based on current user
> permissions.
>
> For resource specific permissions, I'm not sure. Before saying something
> at this regard I need to understand better how are you doing this.
>
>
>>
>> Bill
>>
>
>