You need to sign in to do that
Don't have an account?

Random SSO Issues with SAML Assertion Validator Error
We have seen the SSO errors with Salesforce happen sporadically. Any advice? Here is the error I get:
Single Sign-On Error
We can't log you in. Check for an invalid assertion in the SAML Assertion Validator (available in Single Sign-On Settings) or check the login history for failed logins.
The logins will work in subsequent attempts. Here's what I've found in the login history. As you can see, the login succede and fail randomly:
Username Login Time (Eastern Daylight Time) Source IP Login Type Status Browser Platform Application Client Version API Type API Version Login URL TLS Protocol TLS Cipher Suite Country Code Country Subdivision City PostalCode Latitude Longitude
abc@abc.com 1/19/2017 9:30 209.36.16.130 SAML Sfdc Initiated SSO Success Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384 US United States Rhode Island West Warwick 2893 41.697 -71.5254
abc@abc.com 1/19/2017 9:05 209.36.16.130 SAML Sfdc Initiated SSO Failed: InResponseTo Invalid Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384
abc@abc.com 1/19/2017 9:05 209.36.16.130 SAML Sfdc Initiated SSO Failed: InResponseTo Invalid Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384
abc@abc.com 1/19/2017 9:02 209.36.16.130 SAML Sfdc Initiated SSO Success Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384 US United States Rhode Island West Warwick 2893 41.697 -71.5254
abc@abc.com 1/19/2017 8:56 209.36.16.130 SAML Sfdc Initiated SSO Failed: InResponseTo Invalid Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384
Single Sign-On Error
We can't log you in. Check for an invalid assertion in the SAML Assertion Validator (available in Single Sign-On Settings) or check the login history for failed logins.
The logins will work in subsequent attempts. Here's what I've found in the login history. As you can see, the login succede and fail randomly:
Username Login Time (Eastern Daylight Time) Source IP Login Type Status Browser Platform Application Client Version API Type API Version Login URL TLS Protocol TLS Cipher Suite Country Code Country Subdivision City PostalCode Latitude Longitude
abc@abc.com 1/19/2017 9:30 209.36.16.130 SAML Sfdc Initiated SSO Success Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384 US United States Rhode Island West Warwick 2893 41.697 -71.5254
abc@abc.com 1/19/2017 9:05 209.36.16.130 SAML Sfdc Initiated SSO Failed: InResponseTo Invalid Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384
abc@abc.com 1/19/2017 9:05 209.36.16.130 SAML Sfdc Initiated SSO Failed: InResponseTo Invalid Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384
abc@abc.com 1/19/2017 9:02 209.36.16.130 SAML Sfdc Initiated SSO Success Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384 US United States Rhode Island West Warwick 2893 41.697 -71.5254
abc@abc.com 1/19/2017 8:56 209.36.16.130 SAML Sfdc Initiated SSO Failed: InResponseTo Invalid Chrome 55 Windows 7 Browser N/A N/A N/A abc.my.salesforce.com TLS 1.2 ECDHE-RSA-AES256-GCM-SHA384
what's the life time of your SAML assertions?
What's the time sync of your SAML server and your client?
I have observed these errors when the platforms treats the SAML assertion as expired... if any thing else is indeed valid
alongside also check the time of the client and the server for differences
in the SAML assertion you will find a tag like this: ginving you the time when it was issued
and as well, usually a bit down in it a tag with showing the Time slot of validatiy for this assertion.
in above example it is time of issuing the assertion + / - 5 minutes. This time interval is adjusted on the server - as e.g. mentioned here: https://ping.force.com/Support/PingFederate/Administration/Accounting-for-Time-Drift-Between-SAML-Endpoints50907
see also:
https://stackoverflow.com/questions/29508906/notonorafter-in-subjectconfirmationdata-and-conditions-and-sessionnotonorafter
So - in your case check the validatiy slot, potential network runtimes and see if this helps you undertstanding the behavior