[keycloak-user] UMA PAT clarification

[Pedro Igor Silva]

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
>