On Fri, May 12, 2017 at 12:37 PM, Bill Burke <bburke(a)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(a)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