[keycloak-dev] [authz] All permissions must pass?
Bill Burke
bburke at redhat.com
Sun Apr 2 19:10:08 EDT 2017
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 at redhat.com
> <mailto:bburke at 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 at redhat.com
>> <mailto:bburke at 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 at redhat.com <mailto:bburke at 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/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/permission/scope/776b79cf-57e2-4b55-b9e5-84195c89fd7a
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/permission/scope/776b79cf-57e2-4b55-b9e5-84195c89fd7a>>*decision
>>> was*PERMIT*by*UNANIMOUS*decision.
>>>
>>> * *role.policy.realm-managementmanage-users
>>>
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/policy/role/29968cd1-f44e-47db-868d-c7bd61b827dd
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/policy/role/29968cd1-f44e-47db-868d-c7bd61b827dd>>*voted
>>> to*PERMIT*.
>>> * *role.policy.realm-managementmanage-authorization
>>>
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/policy/role/c4da0818-432a-41d2-94a8-0fc08051a609
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/policy/role/c4da0818-432a-41d2-94a8-0fc08051a609>>*voted
>>> to*PERMIT*.
>>>
>>> # *role-mapper-permission
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/permission/scope/e8acb66c-fe1f-4310-946a-fbb638449e77
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/permission/scope/e8acb66c-fe1f-4310-946a-fbb638449e77>>*decision
>>> was*DENY*by*UNANIMOUS*decision.
>>>
>>> * *role-mapper
>>>
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/policy/role/41b7d1fe-c40f-4437-93d2-aa5768227fd4
>>> <http://localhost:8180/auth/admin/master/console/#/realms/test/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resource-server/policy/role/41b7d1fe-c40f-4437-93d2-aa5768227fd4>>*voted
>>> to*DENY*.
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>>
>>>
>>
>>
>
>
More information about the keycloak-dev
mailing list