[keycloak-dev] restricted admin console access

[Pedro Igor Silva]

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
>