[keycloak-user] shared UMA 2.0 resource & scope based policies

[Pedro Igor Silva]

+1. Or just use the "permissions" response mode while that PR is not merged.

On Wed, Jan 16, 2019 at 10:38 AM Geoffrey Cleaves <geoff at opticks.io> wrote:

> Due to the bugs you and Marco are discussing, you should not use
> response_mode=decision but instead need to examine the scopes that are
> returned in the token.
>
> On Wed, 16 Jan 2019 at 13:36, Marek Lindner <mareklindner at neomailbox.ch>
> wrote:
>
>> On Wednesday, 16 January 2019 20:13:56 HKT Pedro Igor Silva wrote:
>> > Thanks. I think we are on the same page then. Created
>> > https://issues.jboss.org/browse/KEYCLOAK-9337.
>> >
>> > Please, for now, ignore that result and consider the set of the actual
>> > granted permissions.
>>
>> Thanks for opening that bug. However, let me point out that this issue is
>> not
>> limited to the evaluation tool. The UMA policy API evaluation is affected
>> too.
>> Here the call for checking permissions:
>>
>> POST /auth/realms/test/protocol/openid-connect/token
>> grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
>> &permission=2e93c0ea-d5e3-4538-bdf1-47f3c5c67e9b#album:modify
>> &audience=photoz&response_mode=decision
>>
>> returns: {"result":true}
>>
>> Haven't tested RPT tickets but it is somewhat reasonable to assume those
>> are affected too. Looks like the policy logic is fine with any scope
>> shared
>> to grant permission for all scopes.
>>
>> Regards,
>> Marek
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
> --
>
> Regards,
> Geoffrey Cleaves
>
>
>
>
>
>