[keycloak-user] [keycloak-dev] How to share a resource with a user via UMA 2.0 API

Mon May 14 10:28:26 EDT 2018

hi pedro,
that's are not what we can call "user managed authorisation" policies, in
fact are from the "admin" api (and indeed i have been wondering why the
back implementation of current "uma permissions" is not based on "user
policy").
"user managed authorisation" is related to the fact that a user owns the
resource. in practise you could implement "user managed authorisation"
using existing policies (this would actually also avoid the current issue i
reported,
i.e. regarding the complete separation between UMA permissions and policy
based permissions at the evaluation time which leads to the fact that
authorised users with UMA are not listed as authorised when asking access
via permissions)

i copy again the test:

My set-up is a follows:
1. I have a policy that says that the owner of a resource is authorised
with scope read, write and delete. Such policy is attached to a resource
with a * path (e.g. /resource/*).
2. User A create a resource /resource/A
3. User A ask all permissions. He is returned he can do anything on
/resource/A

So far so good. Now it's the part that i believe is not working as i would
expect.

4. User B create a resource /resource/B
5. User B share resource B with User A
6. User A ask all permissions. He is returned he can do anything on /resource/A
but no information is returned about resource B,
    despite there is a permission granted.

It looks like User A can check if he can access resource B only if I create
a permission ticket and I specifically check that, but as a requester,
I don't know in advance if i am authorised to access a resource via UMA
ticket or via another policy.

In fact, if ask if i have read permission using the permission parameter, i
get not authorised:

curl --request POST \
  --url http://127.0.0.1:8080/auth/realms/master/protocol/openid-
connect/token \
  --header 'Authorization: Bearer xxx' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%
3Auma-ticket&permission=da2fdbf6-076e-4716-8b91-
2c7feeda8bee%23read&audience=test'

while if i create a ticket for that resource with permission read, i get
authorised.

federico

On 14 May 2018 at 14:36, Pedro Igor Silva <psilva at redhat.com> wrote:

> We do have endpoints for managing policies via Keycloak Admin REST API.
> From this package:
>
>     https://github.com/pedroigor/keycloak/tree/
> 035ebc881abfe78544861f394c30b1dd9623f879/testsuite/
> integration-arquillian/tests/base/src/test/java/org/
> keycloak/testsuite/admin/client/authorization
>
> You'll find tests for each permission/policy type we support. Is that what
> you are looking for ?
>
> On Mon, May 14, 2018 at 9:25 AM, Federico Michele Facca <
> federico.facca at martel-innovate.com> wrote:
>
>> Hi Pedro, All,
>>
>> I am have been looking a bit more in the permission CRUD operations. I
>> think that it would be better to split the permission ticket from the
>> permission policy themselves.
>> In fact, if i understand correctly the spec, the current permission
>> endpoint should be only used to create the permission ticket. UMA doesn't
>> say anything on how to
>> represent policies so this is totally up to keycloak.
>>
>> Ideally we should have:
>>
>> - /permission
>>   - POST - create a permission ticket
>> - /user-policy (or anything similar)
>>   - POST - create a policy (owner of a resource can create a policy on it
>> without RPT process)
>>   - GET - list policies
>>   - GET /id return a specific policy
>>   - DELETE /id remove a policy
>>   - PUT /id update a policy
>>
>> While at the time being this endpoint may support only "UMA policies"
>> i.e. x request access to y with scope z, and owner grants it,
>> in the future it could allow resource owners to "manage" directly other
>> policies. E.g. allow scope x to all users in group z.
>>
>> For the time being (given that we needed to allow owners to grant
>> directly access to a resource without using an permission ticket),
>> we modified the existing "PUT" to allow the creation of a permission on a
>> resource if the access token used is the one of the resource owner.
>>
>> Best,
>> Federico
>>
>> On 11 May 2018 at 23:43, Federico Michele Facca <
>> federico.facca at martel-innovate.com> wrote:
>>
>>> Hi,
>>>
>>> On 11 May 2018 at 18:04, Pedro Igor Silva <psilva at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Fri, May 11, 2018 at 10:19 AM, Federico Michele Facca <
>>>> federico.facca at martel-innovate.com> wrote:
>>>>
>>>>>
>>>>> Now the first question was how to “share” directly a resource with a
>>>>> user.
>>>>>
>>>>> Currently using the API, supposing I am user A and I want to access a
>>>>> resource Z from user B, we proceed as follow (i hope is the correct way…
>>>>> any correction or guidance will be appreciated):
>>>>>
>>>>> 1.  We create a permission request on the API (to get the ticket).
>>>>> E.g. read resource x
>>>>>
>>>>> 2.  We use the ticket to ask for a rtp token using a user token.
>>>>>
>>>>> curl --request POST \
>>>>>   --url http://127.0.0.1:8080/auth/realms/master/protocol/openid-con
>>>>> nect/token \
>>>>>   --header 'Authorization: Bearer xxx' \
>>>>>   --header 'Content-Type: application/x-www-form-urlencoded' \
>>>>>   --data 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-t
>>>>> icket&ticket=xxxx'
>>>>>
>>>>> If the user has already access, then he gets the rtp, if not he gets:
>>>>>
>>>>> {
>>>>>     "error": "access_denied",
>>>>>     "error_description": "request_submitted"
>>>>> }
>>>>>
>>>>> Only in this moment the permission ticket i created at step 1 appears
>>>>> in the list of permissions. (I am not sure this is the intended behaviour
>>>>> though).
>>>>>
>>>>
>>>> Yeah, that is the expected behavior. But you can also use a request
>>>> parameter to tell to the token endpoint that you don't want to submit an
>>>> authorization request. See https://www.keycloak.org/d
>>>> ocs/latest/authorization_services/index.html#_service_authorization_aat
>>>> .
>>>>
>>>>
>>>>>
>>>>> Then is up to the owner to authorise access (via API we can do that by
>>>>> updating the permission and set granted to true)
>>>>>
>>>>> Now let’s suppose that I am the owner of the resource A, and I want to
>>>>> authorise directly (without the user asking access to the resource A)
>>>>> the user Z to access it. How can I do that? At the time being I could
>>>>> not figure it out.
>>>>>
>>>>
>>>> Similar to the update method, you can use the create method to create
>>>> permissions. Is that what you are looking for ?
>>>> See org.keycloak.testsuite.authz.PermissionManagementTest#te
>>>> stCreatePermissionTicketWithResourceName.
>>>>
>>>
>>> from what i see in the code, permission are persisted only when we
>>> invoking the token api with grant_type=urn:ietf:param
>>> s:oauth:grant-type:uma-ticket
>>>
>>> so in my understanding there is now way (assuming I am the owner of the
>>> resource) to store directly the permission (with grant=true), which would
>>> what
>>> could be the way a user could share directly his resources as it is now
>>> possible in the interface.
>>>
>>> am I wrong?
>>>
>>> i am lost... i see that in the code you refer to i see that you invoke
>>> the token api with grant_type=urn:ietf:params:oauth:grant-type:uma-ticket
>>> you are setting
>>> the claim using the accessToken, but i don't see what this has to do
>>> with the ability of a resource owner to grant directly the access to a
>>> resource (i.e. creating a permission with grant = true)
>>>
>>>
>>> --
>>> *Dr. FEDERICO MICHELE FACCA*
>>> *Head of Martel Lab*
>>> 0041 78 807 58 38
>>> *Martel Innovate* <https://www.martel-innovate.com/>  -  Professional
>>> support for innovation projects
>>> Click to download our innovators' insights!
>>> <https://www.martel-innovate.com/premium-content/>
>>> Follow Us on Twitter <https://twitter.com/Martel_Innovate>
>>>
>>
>>
>>
>> --
>> *Dr. FEDERICO MICHELE FACCA*
>> *Head of Martel Lab*
>> 0041 78 807 58 38
>> *Martel Innovate* <https://www.martel-innovate.com/>  -  Professional
>> support for innovation projects
>> Click to download our innovators' insights!
>> <https://www.martel-innovate.com/premium-content/>
>> Follow Us on Twitter <https://twitter.com/Martel_Innovate>
>>
>
>

-- 
*Dr. FEDERICO MICHELE FACCA*
*Head of Martel Lab*
0041 78 807 58 38
*Martel Innovate* <https://www.martel-innovate.com/>  -  Professional
support for innovation projects
Click to download our innovators' insights!
<https://www.martel-innovate.com/premium-content/>
Follow Us on Twitter <https://twitter.com/Martel_Innovate>