SCIM APIs not working in 4.1

By: Dhanya Kumar KV user 12 Apr 2020 at 8:45 a.m. CDT

6 Responses
Dhanya Kumar KV gravatar
My JUnit testcases for /identity/restv1/scim/v2/Users endpoint worked perfectly in v3.1 but all tests failed in v4.1. I got response Status code : 401 UNAUTHORIZED for /identity/restv1/scim/v2/Users endpoint invocation in v4.1. I verified the cert details using below command, everything looks good. ./opt/amazon-corretto-8.222.10.1-linux-x64/jre/bin/keytool -list -v -keystore /opt/gluu-server/opt/amazon-corretto-8.222.10.1-linux-x64/jre/lib/security/cacerts -alias **HOSTNAME_httpd** I see below exception in logs: 2020-04-12 13:41:15,342 INFO [qtp1058025095-13] [org.gluu.oxtrust.service.filter.AuthorizationProcessingFilter] (AuthorizationProcessingFilter.java:81) - Path is protected, proceeding with authorization processing... 2020-04-12 13:41:15,342 INFO [qtp1058025095-13] [org.gluu.oxtrust.service.uma.ScimUmaProtectionService] (ScimUmaProtectionService.java:102) - ==== SCIM Service call intercepted ==== 2020-04-12 13:41:15,342 INFO [qtp1058025095-13] [org.gluu.oxtrust.service.uma.ScimUmaProtectionService] (ScimUmaProtectionService.java:103) - Authorization header found 2020-04-12 13:41:15,357 ERROR [qtp1058025095-13] [org.gluu.oxtrust.service.uma.BaseUmaProtectionService] (BaseUmaProtectionService.java:81) - Failed to check UMA PAT token status org.gluu.oxtrust.exception.UmaProtectionException: Failed to obtain valid UMA PAT token at org.gluu.oxtrust.service.uma.BaseUmaProtectionService.retrievePatToken(BaseUmaProtectionService.java:123) ~[classes/:?] at org.gluu.oxtrust.service.uma.BaseUmaProtectionService.getPatToken(BaseUmaProtectionService.java:65) ~[classes/:?] Caused by: javax.ws.rs.ProcessingException: RESTEASY004655: Unable to invoke request at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:318) ~[resteasy-client-3.5.1.Final.jar:3.5.1.Final] at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:441) ~[resteasy-client-3.5.1.Final.jar:3.5.1.Final] at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:102) ~[resteasy-client-3.5.1.Final.jar:3.5.1.Final] **Caused by: javax.net.ssl.SSLPeerUnverifiedException: Certificate for <HOSTNAME> doesn't match any of the subject alternative names**: [] at org.apache.http.conn.ssl.SSLConnectionSocketFactory.verifyHostname(SSLConnectionSocketFactory.java:507) ~[httpclient-4.5.11.jar:4.5.11] at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:437) ~[httpclient-4.5.11.jar:4.5.11] Please let me know why am getting SSLPeerUnverifiedException in v4.1
Ubuntu 16.4
closed

Answers

By Mohib Zico Account Admin 16 Apr 2020 at 11:22 a.m. CDT

Copy
Mohib Zico gravatar
@Jose.Gonzalez: can you put some word when you can manage some time please?

By Jose Gonzalez staff 17 Apr 2020 at 8:03 a.m. CDT

Copy
Jose Gonzalez gravatar
> ` Certificate for <HOSTNAME> ...` In that logging statement what's the real value of `HOSTNAME` ? does it match the name of your Gluu installation? for instance, do you actually access oxtrust under `https://<HOSTNAME>/identity` ?

By Dhanya Kumar KV user 17 Apr 2020 at 8:12 a.m. CDT

Copy
Dhanya Kumar KV gravatar
Yes, hostname matches with Gluu installation. I've mentioned the command I used to verify the certificate details in the ticket. I copied the exception trace from /opt/gluu-server/opt/gluu/jetty/identity/logs/oxtrust.log Hope this helps to reproduce the issue on your machine.

By Jose Gonzalez staff 18 Apr 2020 at 3:52 p.m. CDT

Copy
Jose Gonzalez gravatar
Unable to reproduce... I have seen the java exception you highlight in scenarios where an HTTPs request is issued but the domain name in the request does not match the CN of the cert that protects the given resource, so a lookup is made in the alternative names of the cert (in the case of Gluu default cert this is an empty set)

By Jose Gonzalez staff 18 Apr 2020 at 4:01 p.m. CDT

Copy
Jose Gonzalez gravatar
Also recall that if your old 3.1.x installation had the same domain name of your newer Gluu 4.1, you must've removed the old cert and imported the new cert into java trust store where your client code runs.

By Jose Gonzalez staff 02 May 2020 at 4:14 p.m. CDT

Copy
Jose Gonzalez gravatar
One of our customers suffered a similar problem recently. Apparently java does not like certain domain names. Try installing gluu using a more standard name, like `my.box.com`

Post an answer