3:52 p.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user