[keycloak-user] UMA PAT clarification

[Balazs Kovacs]

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