Hi. I would suggest to use a real name for registration, it makes discussion of the issue easier. Back to the issue. Often something like that happens when clocks are out of sync at either/or machines where Gluu, SP and user's browser are running. Even if you'll fix the clock issue, depending on how big this time skew was, you may still end up with outdated certificates, and may need to reinstall some of your packages, or update them manually.

Thank you for the reply. I have updated my forum display name. I have also confirmed that the GLUU server VM, JIRA server (SP) and my local machine are all the same time. They were already the same time, I didn't have to update them, so the certificates should be okay. Is there anything else that would cause this issue?

Please provide: 1. Logs from the IDP and oxAuth. 2. Screenshots of your SAML TR config 3. Screenshots of your SP config in Jira

Hi, Ryan. Sorry for my quick guessing before, it's just quite frequent cause of such kind of issues. As Michael suggested above, you should retry your failing flow and provide us Shibboleth's logs and screenshots of related configuration for a check. You may use any method which you find suitable for sharing them. IdP logs you should share: - `/opt/shibboleth-idp/logs/idp-process.log` - `/opt/gluu/jetty/idp/logs/` oxAuth: - `/opt/gluu/jetty/idp/logs/oxauth.log` More about logging in Gluu CE 3.0 [here](https://gluu.org/docs/ce/3.0.1/operation/logs/)

Thank you for the replies. I placed the files and screenshot in a zip file which I uploaded to Dropbox. Here is the link to the zip file. [Log Files](https://www.dropbox.com/s/2a369fibcccm026/GluuLogs.zip?dl=0) Please let me know if you need any more info from me.

Thanks, Ryan. But I can't see screenshots of your TR's property pages, from Gluu's web UI. Did you include it too? If you didn't, please share it too. So far, this record from `idp-process.log` gives some clues: ``` 2017-03-28 19:16:32,980 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action DecodeMessage: Unable to decode incoming request org.opensaml.messaging.decoder.MessageDecodingException: This message decoder only supports the HTTP POST method at org.opensaml.saml.saml2.binding.decoding.impl.HTTPPostDecoder.doDecode(HTTPPostDecoder.java:57) 2017-03-28 19:16:32,990 - WARN [org.opensaml.profile.action.impl.LogEvent:76] - An error event occurred while processing the request: UnableToDecode ``` Seems like whatever is being provided to Shibboleth's POST binding endpoint is not recognized as a proper SAML request by it. May I ask you to do a capture of what is being sent between SP and Gluu and share this too? Couple of ways you could achieve it: 1. Using **SAML tracer** extension in Firefox 2. Using [FiddlerCap](http://www.telerik.com/fiddler/fiddlercap) tool 3. Using any kind of intercepting web proxy, if you are familiar with that kind of tools.

Alex is right. If you include the screenshots for the Jira app SAML config, the Gluu Server Trust Relationship and the `Configure RelyingParty` modal window, we can probably more effectively provide assistance.

Here are the screenshots: [Screenshots](https://www.dropbox.com/s/h5luqcvk86uz37v/ScreenShots.zip?dl=0) Also, we have nothing configured in the Relaying party window.

Thanks, Ryan. It's another wild guess, but it won't take much time anyway. Could you try to configure Relying Party explicitly, following instructions [here](https://gluu.org/docs/ce/3.0.1/admin-guide/saml/#add-trust-relationship)? So you just need to do only steps related to "Relying Party Configuration" feature and add this "SAML2SSO" element with default settings, then update the TR, ignore everything else there. Then wait for 10 minutes and check whether this helps. Please provide screenshots of resulting configuration after that. Then you should try to create a capture I asked for before, it's hard to say what's happening without it.

Before we continue, I just want to confirm GLUU works the way I think. Currently with ADFS and SAML, when a user goes to a site that we integrated SSO with, they are sent to a sign on Web page. They enter their network credentials and then they are sent to the page they were trying to navigate to. The way I believe GLUU works (and this may be an incorrect assumption), when you go to a site that we integrated SSO and GLUU with, GLUU will have a Web page to sign on and once authenticated, will forward the user to the site they were navigating to. Is that correct?

>The way I believe GLUU works (and this may be an incorrect assumption), when you go to a site that we integrated SSO and GLUU with, GLUU will have a Web page to sign on and once authenticated, will forward the user to the site they were navigating to. Is that correct? Seems like a correct description. In a more detailed view, it would be like this: 1. User accesses some resource where he doesn't have a session yet 2. Resource redirects his browser to one of Shibboleth IdP's endpoints responsible for SSO (Shibboleth is a component of Gluu framework responsible for SAML flows). You can view those endpoints in its metadata at [https://sso.gatewayticketing.com/idp/shibboleth](https://sso.gatewayticketing.com/idp/shibboleth) 3. If user doesn't yet have a session at Shibboleth also, it will redirect him to oxAuth (a core Gluu's component responsible for authentication) and he will be presented with oxAuth's login page. Things may develop differently from here, depending of what authentication method is configured. In the simplest case it will be LDAP bind against internal LDAP directory, or some backend directory (like, your AD servers) 4. After successful authentication a session for this user is created at oxAuth (so normally this user won't be asked to login again for some time) and user is redirected back to Shibboleth, where another session is created automatically (each component has its own sessions, you can say they all "spawn" their session from oxAuth's session). 5. Shibboleth redirects user's browser back to SP with SAML response, and SP makes decision whether to allow this user to access the initial resource.

[Here ](https://www.dropbox.com/s/hjdkiadgmao2qzd/GLUUInfo.zip?dl=0) is the SAML Tracer from Firefox and a screenshot of the Jira configuration in GLUU.

Thanks, Ryan. ``` GET https://sso.gatewayticketing.com/idp/profile/SAML2/POST/SSO?SAMLRequest=pZNfS8MwFMW%2FSsn7mq1WHWGtjIkgKMo6ffAtS%2B9q1vwzN5367c02C31QGQiFQm9y7jm%2FQ2dXH1olO%2FAorSnIJB2TBIywtTRNQZ5WN6MpuSpnyLVybN6FV7OEtw4wJPGeQXYYFKTzhlmOEpnhGpAFwar5%2FR3L0jFz3gYrrCLJHBF8iIsW1mCnwVfgd1LA0%2FKuIK8hOGSUbqXnoxp2acMDvPPPIEULIdpJhdVsmuc5daprpEEa1XYKAt2bQLQkuY7GpOHhkKUXjJMftaisHY3mNlIB3bvN6ONDtaJV9UCS2%2BuCwFbItWidaty2FQ7s2jSw3rRrsEpr6UzbOGFaF08jdnBrMHATCpKNJ5ejcR6f1SRnZ1M2OU8vL85eSPLcc45cSE%2F1cNmfzpP3FEn5f2YzOjRxtJQ59l0y1IfKY10BPoaVZyd3vrDacS9xn1pLI3Wnv5OzofZCxVhL2Ax2nEzhz2OCib10%2FPwYX%2B%2FW18fIP24vj7PfAJQ9reGPUH4B&RelayState=%2F HTTP/1.1 Host: sso.gatewayticketing.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Cookie: JSESSIONID=1y22cj7cm9m86ath1zuug2syg; session_state=c8291489-017c-4d41-80c9-0f6ff27e5111 ``` Why does your SP contact IdP's POST binding endpoint using GET request? That seems to be cause of the issue to me. Are you sure you configured your SP/Jira correctly? On your other screenshot I see that corresponding field on Jira's SAML page is indeed named **"IdP POST binding url"** and you are providing url of POST binding endpoint to Jira, can't see anything wrong there. What do Jira's docs say regarding this? May be you could reference the parts of it you are following when setting this? I'm not sure it's a proper approach here, but perhaps if you'll put url of HTTP-redirect binding endpoint into field **"IdP POST binding url"** on this Jira's SAML config page instead, you may end up with a working setup (as what is being sent seems to be a correct SAML request in format suitable for this kind of binding). Though the actual reason why it doesn't work as it should still probably needs to be investigated. May be this field is simply named incorrectly? To find out your HTTP-redirect binding url please check your metadata for element like this: ``` <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://sso.gatewayticketing.com/idp/profile/SAML2/Redirect/SSO"></SingleSignOnService> ```

Hi, Ryan. Sorry, seems like ticket was closed due to inactivity. Did my last post help in your investigation? Do you still need to keep the ticket open?