[keycloak-user] Managing resource access

Pedro Igor Silva psilva at redhat.com
Mon Aug 27 09:52:33 EDT 2018


Hi Eirik,


We did have an issue on caching which is fixed in upstream master and will
be there in next release.

However, there is something in your "isAreadAdmin" policy that might not
work as expected. When evaluating a policy, Keycloak is actually running
the evaluation for the resource and all requested scopes. That is why you
may see a different result when checking permissions for a specific scope.

If you don't specify a scope, the evaluation will be based on any scope
associated with the resource.

Your JS policy should have something like that to be able to be reused to
evaluate multiple scopes regardless of resources:

```js
var context = $evaluation.getContext();
var client =
$evaluation.authorizationProvider.realm.getClientById($
evaluation.permission.resourceServer.id).clientId;
var permission = $evaluation.permission;
var granted = new Array();
var identity = context.getIdentity();

for (var i = 0; i < permission.scopes.length; i++) {
    var scope = permission.scopes[i];

    if (identity.hasClientRole(client, scope.name)) {
        granted.push(scope);
    }
}

if (granted.length > 0) {
    $evaluation.grant();
    permission.scopes.clear();
    permission.scopes.addAll(granted);
}
```

Note that from JS policies you are free to process requested permissions
(permission.scopes), code above is basically removing any scope that
shouldn't be granted.

On Sat, Aug 25, 2018 at 6:59 AM, Eirik L. Wang <eirilwan at gmail.com> wrote:

> 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
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>


More information about the keycloak-user mailing list