I want to understand that if you have multiple scope/resource
permissions defined for the same scope/resource, how do they evaluate?
It looks like it is
if (permission1 && permission2) then PERMIT
Need to test this out for type permissions and scope-only permissions too.
On 4/1/17 4:00 PM, Pedro Igor Silva wrote:
Now I see. You have two permissions for same resource/scope combo.
They are pretty much conflicting with each other so you will get a DENY.
That is something I was holding for some time where we could provide a
way to configure how permissions decisions are made. Like using those
decision strategies we have for policies with permissions. But I think
we should probably wait for more feedback before doing this. Good
thing is that the way we have things working it is pretty much easy to
provide different configuration options that may change policy
evaluation behavior ....
Sorry, but what you mean by "how multiple permissions are supposed to
evaluate" ? Is it related with the other thread where we are
discussing performance ?
On Sat, Apr 1, 2017 at 4:37 PM, Bill Burke <bburke(a)redhat.com
<mailto:bburke@redhat.com>> wrote:
Policy1: has role FOO, Unanimous, POSITIVE
Policy2: has role BAR, Unamious, POSITIVE
Permission 1: Policy 1 Resource x, Scope y. Unanimous. POSITIVE
Permission 2: Policy 2 Resource x, Scope y. Unamimous. POSITIVE
User role mapping FOO. Evaluate. Failure, User does not have
Scope y on Resource x.
If I remove permission 1 and 2, and aggregate Policy 1 and Policy
2 with Affirmative permission, it does evaluate correctly. I
would actually prefer this behavior, but if I depend on that
behavior, I don't want it changing on me.
Can you please map out how multiple permissions are supposed to
evaluate?
On 4/1/17 3:22 PM, Pedro Igor Silva wrote:
> Sure, if you are getting different results it is a bug. Will look
> at that. Will try to simulate and will ask you for more info if
> needed.
>
> On Sat, Apr 1, 2017 at 4:20 PM, Bill Burke <bburke(a)redhat.com
> <mailto:bburke@redhat.com>> wrote:
>
> The evaluator can't be different than what is returned in the
> RPT,otherwise, what is the point of the evaluator?
>
>
> On 4/1/17 2:19 PM, Pedro Igor Silva wrote:
>> The evaluator may give you this output. But what about the
>> permissions you got in the token (that 'Show Authorization
>> Data` link on top of the result page) ? If you got PERMIT
>> for a scope you should see it in the token.
>>
>> On Sat, Apr 1, 2017 at 1:20 PM, Bill Burke
>> <bburke(a)redhat.com <mailto:bburke@redhat.com>> wrote:
>>
>> So all permissions must pass when evaluating a
>> resource/scope
>> authorization? Just did some testing in admin console.
>> I have 2
>> permissions. I used the policy evaluator for a
>> resource/scope combo.
>> One permission passes, the other fails. Evaluator
>> result is DENY:
>>
>>
>> Result
>> *DENY*
>> Scopes
>> No scopes available.
>> Policies
>> # *map.role.permission.realm-management.manage-authorization
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>> was*PERMIT*by*UNANIMOUS*decision.
>>
>> * *role.policy.realm-managementmanage-users
>>
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>> to*PERMIT*.
>> * *role.policy.realm-managementmanage-authorization
>>
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>> to*PERMIT*.
>>
>> # *role-mapper-permission
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>> was*DENY*by*UNANIMOUS*decision.
>>
>> * *role-mapper
>>
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>>
<
http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13...
>> to*DENY*.
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>> <mailto:keycloak-dev@lists.jboss.org>
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> <
https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>
>