By: Esko Heimonen user 14 Mar 2022 at 5:14 p.m. CDT

2 Responses
Esko Heimonen gravatar
I upgraded Gluu from 4.3.0 to 4.3.1. Before having thoroughly tested the new version, I made the mistake of also adding SCIM to my installed components (from the new install directory). So now I can't say for sure which change caused my problem. My passport is no longer able to access its configuration endpoint when restarted: ``` passport.log: 2022-03-14T20:43:33.132Z [INFO] Loggers reconfigured 2022-03-14T20:43:33.137Z [DEBUG] doRequest. options = { "throwHttpErrors": false } 2022-03-14T20:43:36.329Z [DEBUG] doRequest. response is: { "body": "HTTP 406 Not Acceptable", "statusCode": 500, "headers": { "date": "Mon, 14 Mar 2022 20:43:36 GMT", "server": "Apache/2.4.29 (Ubuntu)", "x-xss-protection": "1; mode=block", "x-content-type-options": "nosniff", "strict-transport-security": "max-age=31536000; includeSubDomains", "content-type": "application/json", "content-length": "23", "connection": "close" } } 2022-03-14T20:43:36.330Z [ERROR] Error: Received unexpected HTTP status code of 500 2022-03-14T20:43:36.330Z [DEBUG] Error: Received unexpected HTTP status code of 500 at /opt/gluu/node/passport/server/utils/uma.js:165:17 at processTicksAndRejections (internal/process/task_queues.js:93:5) 2022-03-14T20:43:36.330Z [WARN] An attempt to get configuration data will be tried again soon ``` uma.js:doRequest expects to receive 401 instead of 500 when no RPT token is granted, so it throws an Error in this case and is never followed by a call to processUnauthorized. Passport thus ends up in an infinite loop trying to re-read its config once per minute. According to last modified timestamp, neither of the Gluu updates changed my /etc/gluu/conf/passport-config.json: ``` { "configurationEndpoint": "https://www.example.com/identity/restv1/passport/config", "failureRedirectUrl": "https://www.example.com/oxauth/auth/passport/passportlogin.htm", "logLevel": "debug", "consoleLogOnly": false, "clientId": "1502.58ec36e5-7458-4c15-bfad-7a44fbadd284", "keyPath": "/etc/certs/passport-rp.pem", "keyId": "b9b5cff5-8398-46dd-abcd-9c5edf14026c_sig_rs512", "keyAlg": "RS512" } ``` Maybe in the correct flow, oxtrust should return 401 instead of 406, so as to catalyze RPT token initialization? ``` jetty.log under identity: 2022-03-14 20:27:26,715 INFO [ForkJoinPool.commonPool-worker-7] [org.gluu.service.logger.LoggerService] (LoggerService.java:205) - Updated log level of '59' loggers to INFO 2022-03-14 20:27:32,129 DEBUG [qtp2085002312-13] [org.gluu.oxtrust.service.filter.AuthorizationProcessingFilter] (AuthorizationProcessingFilter.java:68) - REST call to '/passport/config' intercepted 2022-03-14 20:27:32,152 DEBUG [qtp2085002312-13] [org.gluu.oxtrust.service.filter.AuthorizationProcessingFilter] (AuthorizationProcessingFilter.java:84) - Path is protected, proceeding with authorization processing... 2022-03-14 20:27:32,160 INFO [qtp2085002312-13] [org.gluu.oxtrust.auth.uma.BaseUmaProtectionService] (BaseUmaProtectionService.java:229) - Authorization header not found 2022-03-14 20:27:32,510 ERROR [qtp2085002312-13] [org.gluu.oxtrust.auth.uma.BaseUmaProtectionService] (BaseUmaProtectionService.java:239) - HTTP 406 Not Acceptable at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.handleErrorStatus(ClientInvocation.java:268) ~[resteasy-client-4.5.7.Final.jar:4.5.7.Final] at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.extractResult(ClientInvocation.java:234) ~[resteasy-client-4.5.7.Final.jar:4.5.7.Final] at org.jboss.resteasy.client.jaxrs.internal.proxy.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:62) ~[resteasy-client-4.5.7.Final.jar:4.5.7.Final] at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invokeSync(ClientInvoker.java:151) ~[resteasy-client-4.5.7.Final.jar:4.5.7.Final] at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientInvoker.invoke(ClientInvoker.java:112) ~[resteasy-client-4.5.7.Final.jar:4.5.7.Final] at org.jboss.resteasy.client.jaxrs.internal.proxy.ClientProxy.invoke(ClientProxy.java:76) ~[resteasy-client-4.5.7.Final.jar:4.5.7.Final] at com.sun.proxy.$Proxy141.registerPermission(Unknown Source) ~[?:?] at org.gluu.oxtrust.auth.uma.UmaPermissionService.registerResourcePermission(UmaPermissionService.java:264) ~[oxtrust-service-4.3.1.Final.jar:?] at org.gluu.oxtrust.auth.uma.UmaPermissionService.prepareRegisterPermissionsResponse(UmaPermissionService.java:273) ~[oxtrust-service-4.3.1.Final.jar:?] at org.gluu.oxtrust.auth.uma.UmaPermissionService.validateRptToken(UmaPermissionService.java:220) ~[oxtrust-service-4.3.1.Final.jar:?] at org.gluu.oxtrust.auth.uma.UmaPermissionService.validateRptToken(UmaPermissionService.java:180) ~[oxtrust-service-4.3.1.Final.jar:?] at org.gluu.oxtrust.auth.uma.UmaPermissionService$Proxy$_$$_WeldClientProxy.validateRptToken(Unknown Source) ~[oxtrust-service-4.3.1.Final.jar:?] at org.gluu.oxtrust.auth.uma.BaseUmaProtectionService.processUmaAuthorization(BaseUmaProtectionService.java:167) ~[oxtrust-service-4.3.1.Final.jar:?] ``` I don't find any errors in the restart log of oxtrust. Any suggestions what I need to fix, or how to proceed in order to find the root cause of HTTP 406=>500 at config endpoint?

By Kiran Mali staff 15 Mar 2022 at 12:26 a.m. CDT

Kiran Mali gravatar
“Upgrade” issue is not covered in community tickets until and unless some specific issue vastly impact whole community. But as you raised the problem we will try to take a test internally and see what’s happening there with upgrade when we can grab some time. Thanks for your report.

By Esko Heimonen user 16 Mar 2022 at 1:19 p.m. CDT

Esko Heimonen gravatar
Sorry, I had failed to include the exception stack after the 406. Now included. Might reasteasy-client 4.5.7 be somehow incompatible with v4.3.1 ? Looks like its ClientInvoker.invokeSync (which is implementing "registerPermission" for UMA) gets a response 406 not acceptable.