By: rob cordes user 22 Jan 2020 at 7:36 a.m. CST

6 Responses
rob cordes gravatar
According to the specs : https://docs.kantarainitiative.org/uma/draft-uma-core.html#register-permission Section: 2. Protecting a Resource The resource owner, resource server, and authorization server perform the following actions to put resources under protection. This list assumes that the resource server has discovered the authorization server's configuration data and endpoints as needed. * The authorization server issues client credentials to the resource server. It is OPTIONAL for the client credentials to be provided dynamically through [RFC7591] or [OIDCDynClientReg]; alternatively, they MAY use a static process. * The resource server acquires a PAT (as defined in Section 1.3.1) from the authorization server. A Res Srvr (RS) obtains a PAT (Protection Api Token) during interaction with the ResOwner (RO) which it needs to present to AS upon subsequent client access attempts for registering a Permission ticket. The PAT is supposed to identify / bind RS/set, RO and AS together and allows for indicatign to AS what resource set the client is attempting to access etc. Now the bearer token mentioned in the request to teh AS for registering a permission ticket is referred to as the PAT. What is unclear if it is indeed issued upon registration by RO of the RS set and so unique per user / Ro and RS and AS combination in your implementation. Could you please clarify the behaviour of GLUU wrt PAT tokens? Thx. Rob

By Michael Schwartz Account Admin 22 Jan 2020 at 8:55 a.m. CST

Michael Schwartz gravatar
You can schedule a call at https://gluu.org/booking and I'd be happy to chat with you about it.

By Yuriy Zabrovarnyy staff 22 Jan 2020 at 9:20 a.m. CST

Yuriy Zabrovarnyy gravatar
Rob, First of all you refer to UMA 1.0.1 which is not supported by Gluu 4.0 since it's old. Gluu 4.0 supports UMA 2 only. Spec of UMA 2: * https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-grant-2.0.html * https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html > The PAT is supposed to identify / bind RS/set, RO and AS together and allows for indicatign to AS what resource set the client is attempting to access etc. It seems you refer to this snippet of UMA 1.0.1 spec ``` One circumstance precipitating this action is when the client has attempted access without an RPT (as described in Section 3.1.1). In order for the resource server to know which authorization server to approach and which PAT (representing a resource owner) and resource set identifier to supply, the resource server's API needs be structured in such a way that it can derive this information from the client's RPT-free access attempt. In practice, this information likely needs to be passed through the URI, headers, or body of the client's request. ``` It's about Resource Server implementation. If RS protects resources against multiple AS or use different clients for different resources then RS should handle it in appropriate way. Do you have usecase where you wish to use different clients/PATs for different resources? > Could you please clarify the behaviour of GLUU wrt PAT tokens? If under Gluu here you mean oxauth then from AS perspective it validates PAT during access to Permission Endpoint or Resource Endpoint or RPT introspection. PAT is access_token so it's validated whether token is valid or not. AS knows which client is used for given PAT. Among Gluu products there is oxd middleware which can act as RS. In this context oxd manages PAT per client. If client1 is used to protect/access resources at RS then PAT1 is used. If client2 is used then PAT2 is used. oxd check PAT expiration and re-new it if PAT is expired. oxd is using `client_credentials` grant to obtain PAT. oxd RS API: https://gluu.org/docs/oxd/4.0/api/#uma-2-resource-server-apis Hope it helps, Yuriy Z

By rob cordes user 22 Jan 2020 at 11:17 a.m. CST

rob cordes gravatar
Yes indeed I was confused and read spec 1.0.1 instead of UMA 2.0. So, this PAT concept as a token per Ro (resource) / RS combination has vanished from the spec. Sorry about that, I missed the version nr :-(. Now there is just a client access token per RS/OAUTH2.0 client and the binding between the specific resource is dropped now.

By Michael Schwartz Account Admin 22 Jan 2020 at 12:03 p.m. CST

Michael Schwartz gravatar
I'd be interested to hear about your use case to see if Gluu might be a fit. I would still suggest scheduling a call.

By rob cordes user 22 Jan 2020 at 12:04 p.m. CST

rob cordes gravatar
Sure, let's dot that. I'll send you an email tomorow.

By Mohib Zico staff 30 Jan 2020 at 7:35 a.m. CST

Mohib Zico gravatar
Hi Rob, Think we can close this ticket or you have some question here?