[keycloak-user] UMA PAT clarification

Tue Jun 12 06:50:02 EDT 2018

When creating a resource, you just set the owner property with a value that
could be either the username or id. Something like that
https://github.com/keycloak/keycloak-quickstarts/blob/latest/app-authz-uma-photoz/photoz-restful-api/src/main/java/org/keycloak/example/photoz/album/AlbumService.java#L133
.

I'm going to improve docs for this area.

Thanks.

On Tue, Jun 12, 2018 at 4:12 AM, Balazs Kovacs <balazskov at gmail.com> wrote:

> Hi Pedro,
>
> Thanks for your response.
>
> I think the trade-off you described makes perfect sense. However, I also
> would like to understand how the identity of the resource owner is conveyed
> by the RS to the AS. From the UMA spec, an example resource creation on the
> Protection API looks accordingly:
>
> POST /rreg/ HTTP/1.1 Content-Type: application/json
> Authorization: Bearer MHg3OUZEQkZBMjcx
> ...
> {
>    "resource_scopes":[
>       "read-public",
>       "post-updates",
>       "read-private",
>       "http://www.example.com/scopes/all"
>    ],
>    "icon_uri":"http://www.example.com/icons/sharesocial.png",
>    "name":"Tweedl Social Service",
>    "type":"http://www.example.com/rsrcs/socialstream/140-compatible"
> }
>
> If the RS can do resource protection requests by a PAT that it obtained
> via the client credentials method (and not on users' behalf), through what
> request attribute does the AS learn which resource owner's data the RS is
> talking about? In the end the AS needs to assign each registered resource
> (by RS) to a user account as owner, right? Do maybe the 'resource owner
> password grant' and the 'token exchange' you mentioned above help on that
> by having owner identity in the PAT in these cases? What grant type to use
> for this 'token exchange' method?
>
> Br,
> Balazs
>
> On Mon, Jun 11, 2018 at 5:19 PM, Pedro Igor Silva <psilva at redhat.com>
> wrote:
>
>> We allow the resource server to manage any of its resources regardless of
>> the owner of the resource. You can access the Protection API using a PAT
>> obtained using RS's client credentials.
>>
>> Another you can obtain a PAT is using resource owner credentials grant
>> type.
>>
>> You could also use Token Exchange on the resource server to exchange a
>> regular access token with a PAT where the target audience is the resource
>> server.
>>
>> In all cases, we assume that the owner is granted with a "uma_protection
>> scope" (which is actually a client role within the token) for a
>> particular RS. We also only accept PATs if it was issued to the RS.
>>
>> I understand your point, it is different than what is in the specs. But
>> it simplifies a lot RS implementation when using the protection API to
>> manage resources.
>>
>>
>> On Mon, Jun 11, 2018 at 7:37 AM, Balazs Kovacs <balazskov at gmail.com>
>> wrote:
>>
>>>  Hi,
>>> I'd like some help on clarifying the process of obtaining a PAT token.
>>> I've collected some relevant text from the UMA2 specifications:
>>> ...
>>> "protection API access token (PAT)An [RFC6749]
>>> <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-fed
>>> erated-authz-2.0.html#RFC6749>
>>> access token with the scope uma_protection, used by the resource server
>>> as
>>> a client of the authorization server's protection API. The resource owner
>>> involved in the UMA grant is the same entity taking on the role of the
>>> resource owner authorizing issuance of the PAT."
>>>
>>> ...
>>> "As defined in [UMAGrant]
>>> <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-fed
>>> erated-authz-2.0.html#UMAGrant>,
>>> the resource owner -- the entity here authorizing PAT issuance -- MAY be
>>> an
>>> end-user (natural person) or a non-human entity treated as a person for
>>> limited legal purposes (legal person), such as a corporation. A PAT is
>>> unique to a resource owner, resource server used for resource management,
>>> and authorization server used for protection of those resources. The
>>> issuance of the PAT represents the authorization of the resource owner
>>> for
>>> the resource server to use the authorization server for protecting those
>>> resources."
>>>
>>> ...
>>> "Different grant types for PAT issuance might be appropriate for
>>> different
>>> types of resource owners; for example, the client credentials grant is
>>> useful in the case of an organization acting as a resource owner, whereas
>>> an interactive grant type is typically more appropriate for capturing the
>>> approval of an end-user resource owner. "
>>>
>>> ...
>>> "Use of these endpoints assumes that the resource server has acquired
>>> OAuth
>>> client credentials from the authorization server by static or dynamic
>>> means, and has a valid PAT. Note: Although the resource identifiers that
>>> appear in permission and token introspection request messages could
>>> sufficiently identify the resource owner, the PAT is still required
>>> because
>>> it represents the resource owner's authorization to use the protection
>>> API,
>>> as noted in Section 1.3
>>> <https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-fed
>>> erated-authz-2.0.html#api-sec>.
>>> "
>>>
>>> Apparently, the PAT must represent the identity and consent of the user
>>> to
>>> be used by the resource server at the authorization server, and this is
>>> the
>>> _key_ for the authorization server to know whose resource it is handling.
>>>
>>> In the keycloak documentation, I see an example on how a resource server
>>> can act on its own to grab a PAT token, but I don't see or really know a
>>> straightforward solution how a resource server could get a PAT on behalf
>>> of
>>> a user.
>>> https://www.keycloak.org/docs/latest/authorization_services/
>>> index.html#_service_protection_whatis_obtain_pat
>>>
>>> In case the resource owner is acting, an authorization code flow
>>> conducted
>>> by the user-agent facing client will use the token at the resource
>>> server,
>>> which could be in turn also used by the resource server, if that token
>>> has
>>> 'uma_protection' scope and AS indicated as token audience.
>>>
>>> But how can the RS acquire a valid PAT for the correct resource owner,
>>> when
>>> the requesting-party is trying to access the RS for one of the resource
>>> owner's registered resource? The resource owner is not even in the flow
>>> in
>>> this case
>>>
>>> Can one clarify this a bit how at all circumstances a resource server can
>>> acquire a valid PAT to use on the Protection API so that the AS can
>>> always
>>> conclude the requested owner?
>>>
>>> Br,
>>> Balazs
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>>
>>
>