By: Graham Private user 14 Feb 2019 at 11:14 a.m. CST

6 Responses
Graham Private gravatar
Hi, Following on from the ticket raised, assisted by Yuriy Z and resolved here: https://support.gluu.org/installation/6660/oxd-setup-client-access-token-cannot-be-introspected-due-to-no_setup_client_for_oxd_id/ I have been able to use Postman to interact with OXD via the https-extension to complete the basic UMA protocol flow (without claims gathering), introspecting a provided RPT (w/PAT) to confirm the client has permission to access my protected resource. I'm not sure if I have things confused, but the intention is to protect a publicly available web API, and have client-side software (as the RP) participate from one side, with the server-side API software participate as the RS on the other side. When I completed the workflow using the https-extension however, I found myself needing to use the generated PAT to complete the RP-related activities, such as requesting the RPT. Surely I have something wrong here?! Obviously that also meant that the very basic policy (copied from the SCIM Sample) attached to the UMA Scope needed to permission the very OpenID client I had used to generate the permission ticket for the RP in the first place! Can you help set me straight here? Should the same client be used for both RS & RP requests? If not, what Bearer token should be used in the RP request for an RPT? If there's anything else in my explanation that suggests I've misunderstood, please do point out! Thanks again Graham

By Michael Schwartz staff 14 Feb 2019 at 12:20 p.m. CST

Michael Schwartz gravatar
The RPT endpoint requires client authentication (i.e. client credentials). It's ok for some API's to use clients that use basic authentication. But all forms of basic authentication rely on shared secrets (i.e. the server knows the secret too). It is better security to use asymetric client credentials, where the server only knows a public key, and the client is the only one that knows the private key. UMA requires high security, so the use of private key authentication at the token endpoint is approriate. For this reason, instead of sending the client creds, an OAuth token (client credential grant) is used in lieu of sending the client creds with the request to the RPT endpoint (i.e. the token endpoint in OAuth jargon). But note: an OAuth token obtained via the client credential grant is not a PAT. A PAT was an UMA 1.x thing that does not exist in UMA 2.

By Graham Private user 14 Feb 2019 at 1:51 p.m. CST

Graham Private gravatar
Hi Michael, What you've said about using the `client_credentials` grant to protect the client secret makes sense. The problen I have is that the ValidationService in oxd seems to be treating the request to the token (RPT) endpoint as a PAT, and complains that the token does not have the `oxd` grant, which of course it wouldn't, because it's just the client credentials. ``` 2019-02-14 19:35:04,795 TRACE [org.xdi.oxd.server.service.ValidationService] access_token: a933b772-6035-4a6f-8b75-f531a9706b01, introspection: IntrospectionResponse{active=true, scopes=[], scope=[], clientId='@!3932.OBFUSCATED-FOR-TICKET', username='null', tokenType='bearer', expiresAt=1550173108, issuedAt=1550172808, subject='', audience='@!3932.OBFUSCATED-FOR-TICKET', issuer='https://auth.azya.io', jti='null', acrValues='null'}, setupClientId: @!3932.OTHER-OBFUSCATED-FOR-TICKET 2019-02-14 19:35:04,795 ERROR [org.xdi.oxd.server.Processor] ErrorResponseException{errorResponseCode=ErrorResponseCode{value='protection_access_token_insufficient_scope', description='protection_access_token does not have oxd scope. Make sure a) scope exists on AS b) setup_client is registered with 'oxd' scope c) get_client_token has 'oxd' scope in request'}} at org.xdi.oxd.server.service.ValidationService.validate(ValidationService.java:139) at org.xdi.oxd.server.service.ValidationService.validate(ValidationService.java:49) ``` Note that the introspected token `a933b772-6035-4a6f-8b75-f531a9706b01` was the client_credential token. I don't see any way pass that Validation error other than using the "PAT" originally provided via the oxd-https-extension API's /get-client-token resource...

By Michael Schwartz staff 14 Feb 2019 at 11:56 p.m. CST

Michael Schwartz gravatar
Sorry, I was confused. The client token presented to the oxd API's, with the `oxd` grant, is used to protect the oxd API's themselves. If you are familiar with the architectrue of the Shibboleth SP, there is a service called `shibd`. This always runs on local host... because the authors of the Shibboleth SP didn't want to introduce the complexity of figuring out how to secure shibd over the network. We solved this problem by using OAuth to secure the oxd API's.

By Yuriy Zabrovarnyy staff 15 Feb 2019 at 2:08 a.m. CST

Yuriy Zabrovarnyy gravatar
> When I completed the workflow using the https-extension however, I found myself needing to use the generated PAT to complete the RP-related activities, such as requesting the RPT. Surely I have something wrong here?! I'm not sure I really get the problem. > Should the same client be used for both RS & RP requests? No, usually RS and RP use separate clients. Each calls `setup_client` and `get_client_token` and thus get own `protection_access_token` (one token for RS and one token for RP) which is used to secure access to oxd API's. Important thing here is that this token MUST contain `oxd` scope. Error which you pasted above clearly says what to check. ``` protection_access_token does not have oxd scope. Make sure a) scope exists on AS b) setup_client is registered with 'oxd' scope c) get_client_token has 'oxd' scope in request ``` So does `oxd` scope exist in your AS? Does `setup_client` and `get_client_token` has `oxd` scope (for both RP and RS)? Check whether client LDIF in LDAP really have that scope (find client by `client_id`) > If not, what Bearer token should be used in the RP request for an RPT? The one which you get after `setup_client` and `get_client_token` commands. Same as for RS. Getting access to oxd API's is same for both RS and RP, it doesn't differ. > If there's anything else in my explanation that suggests I've misunderstood, please do point out! Can you explain exact problem ? In your second comment log snippet says that `get_client_token` returned you `protection_access_token` WITHOUT `oxd` scope. So indeed any call to oxd API's will fail with `protection_access_token_insufficient_scope`. Please follow error description and make sure `oxd` scope is really there (on AS, manually check `oxd` scope is in client entry, which is registered by setup_client and then finally `protection_access_token` has that scope). It's definitely configuration problem. One important note. `protection_access_token` which is used to secure oxd API's is one token, in UMA there is PAT (with `uma_protection` scope) which is used by AS Protection API, those are two different tokens. First is to secure oxd API's, second is to secure AS API's. https://docs.kantarainitiative.org/uma/wg/rec-oauth-uma-federated-authz-2.0.html Actually you don't need to think about that second PAT because oxd handles it automatically. Let us know how it goes. Thanks, Yuriy Z

By Graham Private user 19 Feb 2019 at 6:41 a.m. CST

Graham Private gravatar
Forgot to get back to you on this, apologies. What hadn't really clicked for me was the idea that both the RP and the RS need to go through the Register Client phase independently in order to achieve this. I guess I struggled to map the impact of using the OXD service on top of the UMA 2.0 spec. With this important change, I believe everything is working as intended. All looks good, so moving onto implementation. Thanks again, both.

By William Lowe staff 19 Feb 2019 at 7:18 a.m. CST

William Lowe gravatar
Thanks, Graham. If you have any feedback about how to make this clearer on the docs, we are always very appreciative of merge requests to our docs: https://github.com/GluuFederation/docs-oxd-prod/blob/3.1.4/3.1.4/sources/index.md