Hi, Cedric. First thing to check is whether time at IDP is synced properly. If you don't run ntp there yet, proceed to configuring it right now. If you have it installed, try to forcibly sync clocks, and test the flow again: 1. `# service ntpd stop` 2. `# ntpdate -s pool.ntp.org` 3. `# service ntpd start` Also note that SAML-related changes added through web UI make it into IDP's configuration files with a notable delay, up to a few minutes, so may be after you disabled request signature and proceeded to testing they were not applied yet. You can speed this up by restarting `idp` service. If your next test attempt will fail, please also provide your current `idp-process.log` and capture of the flow in a HAR file. You can use steps listed [here](https://www.inflectra.com/support/knowledgebase/kb254.aspx) - please use Firefox for that, 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. Please also note that we only can ensure that guaranteed SLA is met when an account is properly affiliated with a customer's organization is used to create a ticket. As of now you don't seem to be assigned to a group which would grant your account a customer's status, thus your tickets are treated as community user's tickets by the system. They are also publicly visible (any community ticket is), what I suppose you may also wish to avoid. You may want to contact a person on your team which is capable to enlist you there, or ask them to create the ticket instead.

Could it be an ssl error on the client side? Maybe it doesn't like your client https certificate?

Hello, IDP is synced properly. I've set signAssertions to be 'Always' and everything else to be 'Never' in the Relying Party config, then restarted the idp service to apply changes immediately and it is still giving me the same error. So I am attaching the idp-process.log file as well as the HAR file : [Download here](https://files.fm/u/anmnnw8b) The application where the SP is hosted is qliknprinting. Could it be possible that there is a conflict with another SAML TR that is configured in Gluu (we only have 2)? Because that other particular SP (let's call it SP2) is configured to have requests signed and I noticed that when I change its config to not sign requests, the error message when accessing SP1 is different (I get a 'Web Login Service - Unexpected Error. An unexpected error was encountered, usually reflecting a configuration or software error.' instead of the security requirements not being fulfilled). Those 2 SP are supposed to be different, except that SP2 is a sub-module of SP1 and they both have different SAML config and metadata. The name of SP2 is qliksense. In regards to community vs customer, I am well aware of that. We are currently at full capacity for the number of support accounts in our organization so right now I'm OK with opening community tickets and the corresponding delay. Thanks

Hold on, we may have found the issue.. I will update the ticket once it is confirmed.

False alarm, it is NOT resolved. So my last update from Aug 29 is still valid (with the idp-process.log and the HAR file). Thanks

Hi, Cedric. >False alarm, it is NOT resolved. Ok, noted. But could you still briefly explain what was your assumption, and which clues led you to it? It may happen to be an important detail. Could you please also share this IDP's metadata with us? >Could it be possible that there is a conflict with another SAML TR that is configured in Gluu (we only have 2)? Such thing is possible, IDP uses `entityid` property of SP when it searches for locally stored metadata of it. It will accept configuration where several SPs have the same entityid, but only one will be actually used (which one depends on how they'll get ordered after configuration files are processed, and on request's properties). Metadata is stored under `/opt/shibboleth-idp/metadata/`, please make sure it's not the cause.

Another idea, perhaps the key size is a concern of the SP? Maybe update to larger key size?

> Ok, noted. But could you still briefly explain what was your assumption, and which clues led you to it? It may happen to be an important detail. No it is not relevant at all, we thought there was a misconfiguration issue on the SP side but that is not the case. The entityID property for the 2 SP are the same but the ID is different though: SP1 metadata starts with: ... entityID="gluu" ID="_11a35117-75bd-4b4a-b73b-37cebc6bdf62" ... SP2 metadata starts with: ... entityID="gluu" ID="_ba4106dc-7fef-4935-9e0b-964680b39758" ... Could it be the cause of the problem? Gluu's metadata is [here](https://files.fm/u/a4cgykwn).

> Another idea, perhaps the key size is a concern of the SP? Maybe update to larger key size? How ?

>The entityID property for the 2 SP are the same but the ID is different though I don't think it will work like that. You can temporarily press "Deactivate" button for the 2nd SP in Gluu's web UI, then restart "idp" service and re-test. If it will solve the issue, you should try to find a way how to make those 2 SPs use different entityids.

Indeed we have changed the entityID for the 2 SP and it now works better! So I understand that entityID and ID elements must be unique. Thanks!