By: Avi Khetarpal user 15 Oct 2017 at 10:54 p.m. CDT

7 Responses
Avi Khetarpal gravatar
Hi there, We've recently upgraded our Gluu server from 3.0.2 to 3.1.0 and noted that due to the switch from SEAM to WELD, some of the endpoints have changed. That's fine, we understand why, and OpenID Connect is now working after switching to the new endpoint URLs as defined at /oxauth/.well-known/openid-configuration. However, I can't find any information on the new SCIM endpoint URLs. I've guessed that it's something like /identity/restv1/scim/v2/Users and managed to get a proper non-404 response but it's now giving me a SCIM error as below regardless of what URL parameters I pass to the GET request: ``` { "schemas": [ "urn:ietf:params:scim:api:messages:2.0:Error" ], "status": "503", "scimType": "", "detail": "Invalid token" }``` We ARE using SCIM's access token based test mode - I've confirmed that the access token I'm using matches up with what's in the configuration JSON within Gluu. Any ideas? Thanks, Avi

By Arvind Tomar staff 16 Oct 2017 at 7:14 a.m. CDT

Arvind Tomar gravatar
Hi Avi /identity/restv1/scim/v2/Users is now protected with UMA2 instead of uma1 so maybe you need to update your Uma access procedure. Thanks Arvind.

By Avi Khetarpal user 16 Oct 2017 at 2:53 p.m. CDT

Avi Khetarpal gravatar
Hi Arvind, Thanks for your reply. This issue is happening when using SCIM Test Mode with the Access Token, so from my understanding UMA should be bypassed, correct? We're still in a proof of concept/development phase so we hadn't been using UMA at all yet even in 3.0.2 and it was working fine there. Thanks, Avi

By Avi Khetarpal user 16 Oct 2017 at 3:08 p.m. CDT

Avi Khetarpal gravatar
Okay, I think I've found out why I'm getting this issue. The docs at have been updated with some new API access methods but the docs at are still outdated, which is where the confusion came from. Thanks, I'll have a go at modifying our code to use the new, updated access control.

By Avi Khetarpal user 16 Oct 2017 at 9:42 p.m. CDT

Avi Khetarpal gravatar
Hi Arvind, I've tried to go through the new docs and believe I've modified things to work as per the new Basic Authorization scheme for test mode access to SCIM. I'm now getting a 401 Unauthorized response from Gluu: ``` { "error": "invalid_client", "error_description": "Client authentication failed (e.g. unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the Authorization request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the WWW-Authenticate response header field matching the authentication scheme used by the client." } ``` I've tried adding a brand new OpenID Connect client using exactly the same settings as instructed by the docs and I keep getting the above. My new test client's name is SCIM-Client and its secret is authPassword, which I concatenate to SCIM-Client:authPassword and encode in Base64 to get U0NJTS1DbGllbnQ6YXV0aFBhc3N3b3Jk. I'm sending a POST request like so: ``` POST https://____/oxauth/restv1/token HTTP/1.1 Host: ____ Content-Type: application/x-www-form-urlencoded Authorization: Basic U0NJTS1DbGllbnQ6YXV0aFBhc3N3b3Jk grant_type=client_credentials ``` Do you have any ideas on what I might be doing wrong? Thanks, Avi

By Arvind Tomar staff 17 Oct 2017 at 2:33 a.m. CDT

Arvind Tomar gravatar
Hi Avi you can check this scim-node [repo]( Here we have written code and example for how to use scim with new UMA2. Thanks

By Jose Gonzalez staff 17 Oct 2017 at 10:02 a.m. CDT

Jose Gonzalez gravatar
Hi Avi, Decoding your base64 string gives me `SCIM-Client:authPassword` so that part is fine. Can you confirm that when you created your openID client, you used `authPassword` as the client password? (maybe it's not too clear when in the docs it says "Let authPassword be the client secret"). I think you should not use the client name but its Inum (this the real ID of the client). You can find it in oxTrust: Go to Open ID Connect -> clients (second column). Maybe you can share a small ldif showing us the entry of the created client... Find it under `ou=clients,o=<your-org-inum>,o=gluu`

By Avi Khetarpal user 17 Oct 2017 at 3:02 p.m. CDT

Avi Khetarpal gravatar
Hi Jose, thanks for that - using the inum worked. I know I tried the inum earlier too but I must have been missing something else then (maybe a typo in the secret or something) because it too had thrown the same error! Anyway, all good now, thanks! As a suggestion though, you might want to update the docs to say inum where it says "Let authUsername be the name of the client" for clarity. The authPassword line was fine, by the way, and I understood it as intended but I'd just used it as the test client's secret for ease. :) Thanks very much, Avi