By: Blazej A. user 23 Jan 2019 at 9:39 a.m. CST

6 Responses
Blazej A. gravatar
Hi, I have a problem I can't seem to find an answer for. Is it possible to retrieve Requesting Party username or other details in the UMA RPT script? I can verify the client (e.g. the browser, as described in docs) information but how can I check the actual user details? Let say I want to verify if the RP logged in has some ldap role? Does it require to make the additional claim gathering stage? I thought it is possible to simply redirect the RP to OIDC to login, and then use the retrieved AAT token to get the UMA grant token, e.g. the full flow: 1. Get PAT authorizing as 'client' with uma_protection. 2. Get TICKET for the required scopes authorizing as Bearer with PAT. 3. Require user login using openid connect, retrieving AAT. 4. Finally getting the RPT: `curl -X POST -H "Authorization: Bearer ${AAT_token_of_the_logged_in_user}" -H "Content-Type: application/x-www-form-urlencoded" -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Auma-ticket&ticket=${TICKET}' "https://gluu.local/oxauth/restv1/token" ` From my tests I could only make the RPT token request authorizing as the "client" not as the RP (with AAT from OIDC). If I try the above command I get "invalid_client" error from gluu.

By Michael Schwartz staff 23 Jan 2019 at 2:05 p.m. CST

Michael Schwartz gravatar
There is no AAT in UMA 2.0? Are you looking at the right spec? To implement a client, you need to read the [UMA Grant](https://gluu.co/uma-grant) spec. If the user was authenticated at the Gluu Server (during Claims-Garthering flow), the user session is associated with the PCT (via claims). See the sample "UMA RPT Policies" script shipped with the Gluu Server called `uma_rpt_policy` and "UMA Claims Gathering". You can get user claims pretty easily: ``` if context.getClaim("country") == 'US' and context.getClaim("city") == 'NY': ``` Another option is that the UMA client can use the "pushed claim token" feature. This is useful where the Gluu Server is doing authz only, and a different OpenID Provider (or SAML IDP) is performing authn. In this case, you'd push the identity assertion--either an id_token or SAML assertion. But of course you'd have to validate the signature in the RPT script. You could also push the openid connect access token, in which case the RPT script would have to call the Userinfo endpoint. I'm closing the ticket. But post more questions if you can't figure it out after some trial and error.

By Yuriy Zabrovarnyy staff 23 Jan 2019 at 2:44 p.m. CST

Yuriy Zabrovarnyy gravatar
If it's required to get user authentication then you have to redirect user to Claims-Gathering Endpoint and force user to authenticate. After authentication it's possible to fetch all claims that are required and save them in context to use further during RPT Authorization. Here is sample script that has snippet how to force user authentication: https://github.com/GluuFederation/oxAuth/blob/395fc3f0929fbcd5800cbff793fd20c3a4dd5f34/Server/uma/sample/UmaClaimsGathering.py#L60

By Blazej A. user 24 Jan 2019 at 3:57 a.m. CST

Blazej A. gravatar
Hi guys, Thanks! Alright, so I see I need to have claims gathering stage then. Yes I was looking at the right docs, but I was also looking at the OIDC cause in the perfect case I would like to hook the two processes together. Please see the keycloak docs I found on that matter: [Keycloak - requesting RPT](https://www.keycloak.org/docs/3.1/authorization_services/topics/service/authorization/authorization-api-aapi.html) As I understand this: they allow, or even require to use the Bearer AAT token, thus the server knows the basic user claims already and does not require any additional claims gathering. @Michael.Schwartz @Yuriy.Zabrovarnyy What do you think about such a combination of OIDC and UMA? Can I somehow use the AAT to the claims gathering gluu endpoint so that the user has not to be bothered anymore if already authenticated using OIDC if all the necessary claims are there? Kind regards, Blazej

By Michael Schwartz staff 24 Jan 2019 at 4:02 a.m. CST

Michael Schwartz gravatar
We don't care what Keycloak is doing. They are not known for following the specs. And as I stated before, there is no AAT in UMA 2. So that's a *non-sequitur*. Please read the [UMA Grant](https://gluu.co/uma-grant) spec. Or read [chapter 8 of my book](https://gluu.co/book)... or both. Of course UMA / OpenID Connect go together. The latter is an **identity layer**. UMA is neutral on the identity layer. That's why I said you could use either an `id_token` or SAML assertion (pushed claim token), a redirect to an IDP, or a pushed access token for Userinfo.

By Blazej A. user 24 Jan 2019 at 5:27 a.m. CST

Blazej A. gravatar
@Michael.Schwartz As you are a person who contributed to UMA2 spec (btw, I appreciate your work!) I wouldn't like to disagree with you on that matter, but still I cannot see any information in the UMA2 Grant specification which, at least, describes what are the required/acceptable authorization headers and how is the client actually authenticating to the AS in the step from chapter 3.3.1. There is only an example with Basic authorization header, which is not described, actually it doesn't even seem to have base64 value": ``` Authorization: Basic jwfLG53^sad$#f ``` The spec seems incomplete in that matter, and as I was reading the two UMA specs there were several places where the authorization header was not described, not even mentioned. IMHO this could be improved in the specs. If you, or the coauthor of your book is able to update the spec in that matter this would be much more understandable. Thanks, I will try with the pushed access token + userinfo approach. P.S. What I was trying to say is that reusing the OIDC AAT at the authorization header in UMA would be a nice optimization of the flow (assuming that OIDC and UMA go nicely together, and the KISS rule). This way the AS could fetch the claims automatically before executing the policies. Have you ever considered this idea at the UMA work group? Maybe the authorization header part was left undefined in the specs to allow for such things in the first place? If so, have you considered it in gluu?

By Michael Schwartz staff 24 Jan 2019 at 6:22 a.m. CST

Michael Schwartz gravatar
UMA RPT endpont is an OAuth token endpoint, so any supported client authentication is valid, e.g. access_token, client_secret_basic, client_secret_post, private_key_jwt, client_secret_jwt. So yes, UMA client can send access token (in this case authentication_method has to be set to access_token).