By: Vijay sundhar user 26 Apr 2019 at 2:05 a.m. CDT

8 Responses
Vijay sundhar gravatar
We have been working on setting up a Federated identity with SAML. The IDP is GLUU and the SP is WSO2 Identity Services. We were able to integrate by sharing the metadata.xml files from both end. On the SP side, the fields "entity Id" and "SSO URL" holds the URL to be redirected to GLUU to authenticate the users. WE have now 2 scenrios, 1. When the fields are given with the following URL, we get 400 Bad Request. "https://{gluu-hostname}/idp/profile/SAML2/POST/SSO" 2. When it is "https://{gluu-hostname}/identity" , the GLUU login page is getting loaded. It then successfully logs in the user in the GLUU server itself, but there wasn't any SAML response returned or redirected back to the SP, so that SP will be able to provide the authorization code/token to the application/web page, which the user is trying to get access.

By Michael Schwartz Account Admin 26 Apr 2019 at 4:03 a.m. CDT

Michael Schwartz gravatar
To configure the WS02, you can look at the Gluu Server IDP metatdata: ``` https://(your-hostname)/idp/shibboleth ``` You will see `entityID` on the third line. For the "SSO URL", it's unclear which SAML binding they are using. Maybe try: ``` https://(your-hostname)/idp/profile/SAML2/POST-SimpleSign/SSO ``` There are URLs for other binding in the `SingleSignOnService` section of the Gluu Server IDP metadata... you can try those too. If you get it working, please post the answer here so others using WS02 as the SP can benefit! Also, you might want to read the SAML chapter of my book: https;//gluu.co/book

By Vijay sundhar user 03 May 2019 at 1:43 a.m. CDT

Vijay sundhar gravatar
Tried with all 4 URLs that are generated in the metadata.xml file Except redirect URL, everything is getting the stale request error. Redirect URL is getting Web Login Service - Unsupported Request error. Can you suggest any other troubleshooting steps for this?

By Michael Schwartz Account Admin 03 May 2019 at 2:06 a.m. CDT

Michael Schwartz gravatar
Do you see the exact SAML Request? If you can see this, sometimes it really helps with debugging. You can enable debug logging on the IDP (or normally in the SP), so you can see the request. If there is a SAML request, you want to see that too. And of course check all the underlying log files (shib IDP logs, the SP logs, etc). You might get a hint in there.

By Aliaksandr Samuseu staff 13 May 2019 at 9:32 p.m. CDT

Aliaksandr Samuseu gravatar
Hi, Vijay. Do you still need assistance with this issue? Please update us on its current status, and make sure you've followed Michael's suggestions above. The "stale request error" usually happens in two cases: 1. You haven't made sure clocks are syncronised between host where Gluu Server runs, and SP"s host; best solution is to run "ntp" at both of them 2. Somehow, you manage to repeat previous request; that may happen due to abuse of browser's "Back" button (never should be used during authentication flows), due to some weird caching issues, or because your SP for some reason just resends a previously formed SAML request instead of generating a new one each time (as it should) It hardly has to do something with Gluu itself, you need to review your configuration and actions. Two paths you can consider using as "SSO URL" are `https://{gluu-hostname}/idp/profile/SAML2/Redirect/SSO` and `https://{gluu-hostname}/idp/profile/SAML2/POST/SSO` Which one to use depends on your SP's configuration. If you need our further assistance, please also create and share a HAR file with a capture of the whole failing flow. 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. Before recording the HAR file, increase log verbosity for IDP as well: 1. Move into container 2. Preserve previous IDP log file, if needed: `# cp /opt/shibboleth-idp/logs/idp-process.log /opt/shibboleth-idp/logs/idp-process.log.bak` 3. Stop the IDP: `# service idp stop` 4. Edit section "" of the `/opt/shibboleth-idp/conf/logback.xml` file, switch "idp.loglevel.idp", "idp.loglevel.messages" and "idp.loglevel.opensaml" loggers to DEBUG 5. Start the IDP: `# service idp start` Wait for 10 minutes, then re-do the failing flows (after the issue with stale requests is sorted out), collect the complete re-created `idp-process.log` and share it with us together with HAR file you've recorded at the same time.

By Vijay sundhar user 13 May 2019 at 11:26 p.m. CDT

Vijay sundhar gravatar
Thanks for your detailed steps for troubleshooting @Aliaksandr.Samuseu . I will be taking some time(maybe a week or two, middle of some other work) to come back to this with all the required data you mentioned above. But for sure I have to figure out this at any cost and will be needing assistance from you guys.

By Vijay sundhar user 24 May 2019 at 2:33 a.m. CDT

Vijay sundhar gravatar
Hi, Currently there seems a little progress from SP, as the AP metadata got updated. Now I am currently getting the following error in `idp-process.log` ``` 2019-05-24 07:25:53,278 - INFO [org.gluu.oxauth.client.conf.Configuration:170] - Loading configuration from Ldap... 2019-05-24 07:25:53,356 - INFO [org.gluu.oxauth.client.conf.Configuration:95] - Configuration loaded successfully. 2019-05-24 07:25:53,628 - INFO [org.gluu.oxauth.client.OpenIdClient:131] - Successfully loaded oxAuth configuration 2019-05-24 07:25:54,196 - WARN [org.gluu.idp.externalauth.ShibOxAuthAuthServlet:144] - Error processing oxAuth authentication request net.shibboleth.idp.authn.ExternalAuthenticationException: No conversation state found in session for key (e2s1) at net.shibboleth.idp.authn.ExternalAuthentication.startExternalAuthentication(ExternalAuthentication.java:142) ``` And the following error page, ``` "Sorry, it looks like there is a problem finding your session. This can happen if you waited too long on the login page, or if you were redirected to a different server that issued the original request. This error usually goes away if you try accessing your desired application again." ``` But even after many retries, am getting same error and error page.

By Michael Schwartz Account Admin 24 May 2019 at 4:17 a.m. CDT

Michael Schwartz gravatar
I wonder if it's a NameID problem. If you can enable debug logging on Shibboleth so you can see the SAML request from the SP, and paste it here, that would help.

By Mohib Zico staff 30 May 2019 at 1:26 p.m. CDT

Mohib Zico gravatar
Yes... [here](https://gluu.org/docs/ce/3.1.6/operation/logs/#adjust-shibboleth-log-level) is how you can enable shibboleth debug.