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

[Pedro Igor Silva]

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>
>