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

Mon May 14 13:05:10 EDT 2018

I see now...

We could solve your current issue by fixing the processing of entitlement
requests to also consider permissions granted by a user via permission
tickets. This is the easiest solution ...

However, I think we would be still limiting users regarding the different
policies they can use to protect their resources. For instance, today a
permission granted directly by the user (and backed by a permission ticket
approved by this same user) takes precedence over whatever policy you have
defined to a resource.

We could start using a policy (and not the ticket) to decide whether or not
the user is granted access to someone else resource. In fact, it would make
sense to use an Aggregated Policy to combine whatever policy the user has
defined to rule access to a resource. The current implementation is using
the ticket because users can only decide to share a resource or not,
regardless of other conditions.

The "/user-policy" endpoint you mentioned would be basically managing the
"Aggregated Policy" associated with a specific resource by adding and
removing whatever policy the user wants to define.

Does it make sense for you?

On Mon, May 14, 2018 at 11:28 AM, Federico Michele Facca <
federico.facca at martel-innovate.com> wrote:

> 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/035ebc881abfe78
>> 544861f394c30b1dd9623f879/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_author
>>>>> ization_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>
>