[keycloak-dev] [authz] All permissions must pass?

[Pedro Igor Silva]

+1. However, if a scope-based permission we GRANT any scope that got a
PERMIT. In your case, this is not true because you got a DENY for the same
scope and that removes it from the list of granted scopes.

On Sun, Apr 2, 2017 at 8:10 PM, Bill Burke <bburke at redhat.com> wrote:

> 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> 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> 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> 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/te
>>>> st/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resour
>>>> ce-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/te
>>>> st/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resour
>>>> ce-server/policy/role/29968cd1-f44e-47db-868d-c7bd61b827dd>*voted
>>>>     to*PERMIT*.
>>>>   * *role.policy.realm-managementmanage-authorization
>>>>     <http://localhost:8180/auth/admin/master/console/#/realms/te
>>>> st/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resour
>>>> ce-server/policy/role/c4da0818-432a-41d2-94a8-0fc08051a609>*voted
>>>>     to*PERMIT*.
>>>>
>>>> # *role-mapper-permission
>>>> <http://localhost:8180/auth/admin/master/console/#/realms/te
>>>> st/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resour
>>>> ce-server/permission/scope/e8acb66c-fe1f-4310-946a-fbb638449e77
>>>> >*decision
>>>> was*DENY*by*UNANIMOUS*decision.
>>>>
>>>>   * *role-mapper
>>>>     <http://localhost:8180/auth/admin/master/console/#/realms/te
>>>> st/clients/b13a8867-5d75-4c8b-8927-5e806bd77518/authz/resour
>>>> ce-server/policy/role/41b7d1fe-c40f-4437-93d2-aa5768227fd4>*voted
>>>>     to*DENY*.
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>
>>>
>>>
>>
>>
>
>