[keycloak-dev] [authz] All permissions must pass?
Bill Burke
bburke at redhat.com
Mon Apr 3 09:23:57 EDT 2017
Ok, the behavior is:
if (scope-only-permission AND resource-type-permission AND
specific-resource-scope-permission) then PERMIT
So, if you want different conditions to PERMIT than what is currently
constrained by the default scope permission or resource type permission
you can't do this.
On 4/3/17 7:24 AM, Pedro Igor Silva wrote:
> +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
> <mailto: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
>> <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