[keycloak-dev] restricted admin console access

[Bill Burke]

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 
> <mailto: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.

Bill