[keycloak-user] Managing resource access

Eirik L. Wang eirilwan at gmail.com
Sat Aug 25 05:59:49 EDT 2018


Hi,

We have a customer support portal where we are trying to use Keycloak for
managing resources.

As part of our portal we want to be able to show admins who has access to a
given resource. Is it possible to get this information from the
authorization api's?
I'm mostly using RBAC, so our backup plan is just showing this information
based on role membership. But it would be nice to be able to show
calculated access, as there might be some special rules for some resources.

Also, area you able to explain some curious behavior to me? It might be
that I'm not fully aware on how the evaluation of permissions is happening:

This is what I have drilled it down to:
Say I have 2 resorces
area_1
area_2
each with scopes
area_1:read
area_2:read
area_1:write
area_2:write

I have two policies:
IsAdmin policy that checks for a client admin role
IsAreaAdmin - a generic js policy which tries to check for a role
corresponding with the scope accessed
eg: check if user is member of area_1:write client role

Js-code:
var context = $evaluation.getContext();
var id = $evaluation.permission.resourceServer.id;
var client =
$evaluation.authorizationProvider.realm.getClientById(id).clientId;
var scope = $evaluation.permission.scopes[0].name;
var identity = context.getIdentity();
logger.warn("evaluating " + scope)
logger.warn("evaluating " + identity.hasClientRole(client, scope))
if(identity.hasClientRole(client, scope)){
    $evaluation.grant();
}


Then I have scope based permissions (one for each scope) Affirmate with
both scopes.
So either you are admin, or you have a role corresponding with the scope.

Testing this:

User1 is member of area1:read client role

When evaluating user with only area1:read scope - access is granted
When evaluating user with any resource, any scope - access is denied

Debugging, it seems like only one of the scopes are tested through the
policy for each resource.
Is this expected behavior? Or is there a caching bug somewhere?


Regards
Eirik Wang


More information about the keycloak-user mailing list