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

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?

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.

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.

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.

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.

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.

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