By: Hector Rodriguez user 20 Sep 2017 at 4:31 a.m. CDT

6 Responses
Hector Rodriguez gravatar
Hello there, I've been testing Gluu's UMA 2.0 implementation and found some errors related to RPT policy scripts. The documentation available [here](https://gluu.org/docs/ce/api-guide/uma-api/#uma-authorization-context) summarizes all methods available on the "context" object. I'm most interested on checking some user attributes by using the following listed method: ``` getUser(String... returnAttributes) - returns logged in user attributes ``` When trying to access this method through intermediate scripts (with the line _context.getUser("param")_), Python throws an AttributeError. When performing a "dir" command on the context object, the following methods seem to be available: ``` ['__class__', '__copy__', '__deepcopy__', '__delattr__', '__doc__', '__ensure_finalizer__', '__eq__', '__format__', '__getattribute__', '__hash__', '__init__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__subclasshook__', '__unicode__', 'addRedirectUserParam', 'claims', 'class', 'configurationAttributes', 'equals', 'getClaim', 'getClaims', 'getClass', 'getConfigurationAttributes', 'getHttpRequest', 'getIpAddress', 'getIssuer', 'getLog', 'getRedirectUserParameters', 'getRedirectUserParametersMap', 'getResourceIds', 'getResources', 'getScopeMap', 'getScopes', 'getScriptDn', 'getScriptScopes', 'hasClaim', 'hashCode', 'httpRequest', 'ipAddress', 'isInNetwork', 'issuer', 'log', 'notify', 'notifyAll', 'putClaim', 'redirectUserParameters', 'redirectUserParametersMap', 'removeClaim', 'removeRedirectUserParameter', 'resourceIds', 'resources', 'scopeMap', 'scopes', 'scriptDn', 'scriptScopes', 'toString', 'wait'] ``` As you can see, this context has no getUser method. **Is this an intended behaviour? If so, is there any workaround to retrieve user attributes in the UMA RPT intermediate script?** Thank you for your time in advance. Kind regards, Hector

By Yuriy Zabrovarnyy staff 20 Sep 2017 at 8:36 a.m. CDT

Yuriy Zabrovarnyy gravatar
Hi Hector, Which CE version do you use ? Is it `3.1.0` or `3.1.1` ? If it's `3.1.0` then it is not available there. It's enabled only in `3.1.1`. You can read how to upgrade in below link as well as how to use UMA 2 standard flow to fetch user attributes in `3.1.0`. ``` https://support.gluu.org/access-management/4524/passing-user-info-as-claim-to-uma-2/ ``` Thanks, Yuriy Z

By Hector Rodriguez user 20 Sep 2017 at 8:45 a.m. CDT

Hector Rodriguez gravatar
Hi Yuriy, My version is 3.1.0. I think the link you've provided in your message might be useful but it throws the following error: ``` You are not authorized to view this ticket. If you think this is a mistake, please email support@gluu.org. ``` Thanks, Hector

By Yuriy Zabrovarnyy staff 20 Sep 2017 at 9:47 a.m. CDT

Yuriy Zabrovarnyy gravatar
Hector, Inlining it below ... CE 3.1.0 does not have this convenient `getUser(String... returnAttributes)` method in UMA RPT Authorization Policy script (present in `3.1.1`) but it exists in Claims-Gathering Context of Claims-Gathering Script. We would have to follow full UMA 2 workflow in CE `3.1.0` to fetch `uid` of logged in user (again, it's only if `uid` is not provided by PCT or `claim_token`): 1. define `uid` as required claim in `getRequiredClaims()` method (sample here)[https://gluu.org/docs/ce/3.1.0/admin-guide/uma/#uma-rpt-authorization-policies] 1. since `uid` is not provided user will be redirected to Claims-Gathering Endpoint 2. get claim in Claims-Gathering script (via `getUser(String... returnAttributes)` method) 3. put claim into context of Claims-Gathering script and `persist()` it 4. then on redirect back inside UMA RPT Authorization Policy you would be able to get claim as `context.getClaim("uid")`. In CE `3.1.1` it's of course much simpler. ``` context.getUser('uid') ``` `3.1.1` is not officially released. It should be ready soon. You can try to upgrade oxauth to `3.1.1` (it works on my PC) but it is not official way of upgrading and it does not passed QA process. First of all login ``` service gluu-server-3.1.0 login ``` Upgrade schema ``` service solserver stop cd /opt/gluu/schema/openldap/gluu.schema wget https://raw.githubusercontent.com/GluuFederation/community-edition-setup/version_3.1.1/static/openldap/gluu.schema service solserver start ``` Update oxauth ``` service oxauth stop cd /opt/gluu/jetty/oxauth/webapps wget http://ox.gluu.org/maven/org/xdi/oxauth-server/3.1.1-SNAPSHOT/oxauth-server-3.1.1-SNAPSHOT.war -O oxauth.war service oxauth start ``` Thanks, Yuriy Z

By Hector Rodriguez user 21 Sep 2017 at 3:14 a.m. CDT

Hector Rodriguez gravatar
Yuriy, I have question that I've been trying to answer by reading your source code, but I don't want to leave this ticket hanging so I'll just share it here: Regarding step 2 of the flow you have presented. Is this redirecting step supposed to be implemented client side or server side? When trying to request a token using the ticket provided by the AM server, I get a 403 Forbidden response containing (example): ``` { "error": "need_info", "ticket": "2325659d-4469-4c2a-8b3b-ecc05617f6de", "required_claims": [ { "issuer": [ "%1$s" ], "name": "uid", "claim_token_format": [ "http://openid.net/specs/openid-connect-core-1_0.html#IDToken" ], "claim_type": "string", "friendly_name": "uid" } ], "redirect_user": "https://nextgeoss-sso-ref.elecnor-deimos.com/oxauth/restv1/uma/gather_claims" } ``` Am I supposed to just leverage this redirect client-side like UMA 2.0 suggests? Thanks, Hector

By Yuriy Zabrovarnyy staff 21 Sep 2017 at 4:40 a.m. CDT

Yuriy Zabrovarnyy gravatar
Hector, It is client side redirect. Required paramerts for Claims-Gathering Endpoint are listed in `3.3.2` section of UMA 2 [specification](https://docs.kantarainitiative.org/uma/ed/oauth-uma-grant-2.0-07.html#rfc.section.3.3.2). In CE `3.1.0` `redirect_uri` returns location of Claims-Gathering Endpoint and custom parameters (if they are added in the script), client has to append all further required parameters, like: `client_id`, `ticket`, `claims_redirect_uri` and recommended `state`. In CE `3.1.1` AS already appends following parameters: `client_id`, `ticket` (plus custom parameters if specified). Then it's responsibility of client to append `claims_redirect_uri` and recommended `state`. In CE `3.1.1` it should be possible to make a trick and add `claims_redirect_uri` via script (`context.addRedirectUserParam("claims_redirect_uri", "<registered before client claims_redirect_uri here>")`). It all depends on where you wish to keep control of it. Thanks, Yuriy Z

By Hector Rodriguez user 21 Sep 2017 at 8:11 a.m. CDT

Hector Rodriguez gravatar
Hello Yuriy, Thank you very much for your answers and your help. I'm closing this ticket, since I have no questions left. Hector