Infinite Redirect using Inbound SAML

By: Dennis Reichenberg user 06 Jun 2019 at 2:24 a.m. CDT

11 Responses
Dennis Reichenberg gravatar
Hi Gluu team and community, we've been tinkering around with the inbound SAML functionalities of Gluu for quite some time now, everything seems to be working fine until the user that authenticated is stuck inside an infinite redirect loop between the test IdP (which happens to be a Gluu Server aswell) and our Inbound SAML server. The scenario looks like this: 1. The user opens our application 2. The user enters his email address and clicks the login button 3. The OpenID connect request is sent to the Inbound SAML server with the information what IdP the user should authenticate with 4. The user successfully logs into his IdP and is redirected to our Inbound SAML server 5. The user is now stuck in a redirection loop between `passport/auth/saml/<STRATEGY>/<SOME-JWT-TOKEN>` on our Inbound SAML server and `idp/profile/SAML2/POST/SSO` on the IdP server The passport logs seem to indicate that some value has been missing in the callback: ``` 2019-06-06T08:19:02+0200 [INFO] User authenticated with userid "<USER>" and strategy "<STRATEGY>" 2019-06-06T08:19:02+0200 [ERROR] Unknown Error: TypeError: Cannot read property 'server_uri' of undefined 2019-06-06T08:19:02+0200 [INFO] ::ffff:127.0.0.1 - - [06/Jun/2019:06:19:02 +0000] "POST /passport/auth/saml/<STRATEGY>/callback/inbound HTTP/1.1" 302 74 "https://<IDP>/idp/profile/SAML2/POST/SSO" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/74.0.3729.169 Chrome/74.0.3729.169 Safari/537.36" ``` Skipping the OpenID connect request in favor of SAML worked fine, but we were unable to skip the IdP selection page using that method, so we started adapting the documented OpenID connect workflow. The documentation states, that an infinite redirect loop might be caused by clock skew on the involved servers, but this should not be the case for us, as we are using the same NTP server for all our machines. I could not find anything about this issue yet, so I'm hoping that maybe someone here is able to point out our misconfiguration of the servers. Thanks in advance, Dennis
Debian 9.9
closed

Answers

By Aliaksandr Samuseu staff 06 Jun 2019 at 5:31 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Dennis. Let's do a quick test. Check JSON in `/etc/gluu/conf/passport-inbound-idp-initiated.json` file, and make sure it has `server_uri` property in it (note the underscore, i.e. `serveruri` is NOT correct). If it has something like `serveruri` in it, change it to `server_uri`, then restart "passport" service and re-try the flow. If that suggestion won't help, please do next: 1. Edit ` /etc/gluu/conf/passport-config.json` file by changing "logLevel" property in it to "debug" 2. Restart "passport" service 3. Re-try the failing flow, while saving a trace of it, then export that trace as HAR file. You can use steps listed [here](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that task, Chrome's HARs are flawed. Also don't forget to set "Persist log" and "Disable cache" checkboxes in the console to save everything, not just the recently loaded page. Then share the HAR file together with logs in `/opt/gluu/node/passport/server/logs/passport.log` and `/opt/gluu/jetty/oxauth/logs/oxauth_script.log` with us.

By Dennis Reichenberg user 06 Jun 2019 at 5:52 a.m. CDT

Copy
Dennis Reichenberg gravatar
Hi Aliaksandr, thank you for your quick reply. The `passport-inbound-idp-initiated.json` file looks like this on the inbound server: ``` { "<STRATEGY>": { "openidclient": { "server_uri": "", "client_id": "" }, "authorization_params": { "client_id": "", "redirect_uri": "", "acr_values": "passport_saml", "response_type": "code", "scope": ["openid", "user_name", "email"] } } } ``` Is it correct to have an empty string as the value for `server_uri`? If no, then what URI would I need to enter there that would allow our inbound server to connect with a Gluu IdP?

By Aliaksandr Samuseu staff 06 Jun 2019 at 6:01 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
My mistake, sorry. Memory failed me about this part. It's about "openidclient" bit, not "server_uri". Please try to change "openidclient" to "openid_client" instead, then restart Passport and re-try the flow. If it won't help, please follow the rest of suggestions from before.

By Aliaksandr Samuseu staff 06 Jun 2019 at 6:04 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
>Is it correct to have an empty string as the value for server_ur Yes, that's okay. It's a stub configuration block used for a niche specific flow not related to your case. I just saw a familiar error in your logs which was releated to another similar issue.

By Dennis Reichenberg user 06 Jun 2019 at 6:42 a.m. CDT

Copy
Dennis Reichenberg gravatar
> Please try to change "openidclient" to "openid_client" instead, then restart Passport and re-try the flow. If it won't help, please follow the rest of suggestions from before. Thank you! This change actually stopped the infinite redirect loop, but now we are getting stuck when the user is redirected to `passport/auth/saml/<STRATEGY>/callback/inbound`. The request will load for some time and after that the user will be greeted with a 502 response code and the message: ``` Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /passport/auth/saml/<STRATEGY>/callback/inbound. Reason: Error reading from remote server Apache/2.4.25 (Debian) Server at <INBOUND SAML SERVER> Port 443 ``` This is the last thing that is written to the `passport.log`: ``` 2019-06-06T13:33:50+0200 [VERBOSE] Using inboung IDP config: {"openid_client":{"server_uri":"","client_id":""},"authorization_param s":{"client_id":"","redirect_uri":"","acr_values":"passport_saml","response_type":"code","scope":["openid","user_name","email"]}} 2019-06-06T13:33:50+0200 [VERBOSE] getAuthorizationEndpoint called for: ```

By Aliaksandr Samuseu staff 06 Jun 2019 at 6:50 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Something isn't right here. It shouldn't get to `/inbound` under normal conditions. This endpoint is only used in case of IDP-initiated Inbound Passport-SAML, which is an experimental feature developed per customer's request, for their specific purpose. Please gather the information requested earlier (HAR + logs) and share with us, we need to see how the flow proceeds.

By Aliaksandr Samuseu staff 06 Jun 2019 at 6:53 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Also, please share contents of your `/etc/gluu/conf/passport-saml-config.json` file.

By Dennis Reichenberg user 06 Jun 2019 at 7 a.m. CDT

Copy
Dennis Reichenberg gravatar
> Also, please share contents of your /etc/gluu/conf/passport-saml-config.json file. This is what the file looks like on our inbound server: ``` { "<STRATEGY>": { "entryPoint": "https://<IDP Hostname>/idp/profile/SAML2/POST/SSO", "authnRequestBinding": "HTTP-POST", "issuer": "<INBOUND_HOSTNAME>", "identifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:transient", "additionalAuthorizeParams": "", "logo_img":"<LOGO_URL>", "enable":"true", "cert" : "<CERT>", "skipRequestCompression": "true", "reverseMapping": { "email" : "email", "username": "urn:oid:0.9.2342.19200300.100.1.1", "displayName": "urn:oid:2.16.840.1.113730.3.1.241", "id": "urn:oid:0.9.2342.19200300.100.1.1", "name": "urn:oid:2.5.4.42", "givenName": "urn:oid:2.5.4.42", "familyName": "urn:oid:2.5.4.4", "provider" :"issuer" } } } ``` > Please gather the information requested earlier (HAR + logs) and share with us, we need to see how the flow proceeds. I have to get hold of my boss first, because I don't know whether I can share this data with you. I never heard of the HAR format before and I will probably have to anonymize the data before I can send it to you.

By Aliaksandr Samuseu staff 06 Jun 2019 at 7:30 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
I understand. For now, let's try one more quick test. In `/etc/gluu/conf/passport-saml-config.json`, change the id of your IDP from "<STRATEGY>" to something else (we usually use something like "idp1", "idp2".."idpn" there). Anything will do, the point is that it must not match the id from `passport-inbound-idp-initiated.json`

By Aliaksandr Samuseu staff 06 Jun 2019 at 7:30 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
After the change, restart "passport" service and re-try the flow.

By Dennis Reichenberg user 06 Jun 2019 at 9:02 a.m. CDT

Copy
Dennis Reichenberg gravatar
Thank you Aliaksandr! Renaming the identifier solved the issue for us.

Post an answer