SAML assertion could not be validated error

An error stating SAML Assertion could not be validated. Please contact your administrator. Retry Now. could be caused by an expired certificate (Figure 1):


Figure 1 Error

If the certificate hasn't already expired, it may be due to expire within two weeks as ADFS invalidates any primary or secondary certificates expiring within this time period.

Note: Further information on token certificate renewal can be found here.

To resolve this error, regenerate the certificate and upload the primary certificate to the pod.

Alternatively, check the SAML response during this error. A SAML Response is sent by the Identity Provider (IDP) to the Service Provider (SP) if the user succeeds in the authentication process, otherwise there is no response. An example SAML response is below (Figure 2):

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_8e8dc5f69a98cc4c1ff3427e5ce34606fd672f91e6" Version="2.0" IssueInstant="2014-07-17T01:01:48Z" Destination="" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
<saml:Assertion xmlns:xsi="" xmlns:xs="" ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version="2.0" IssueInstant="2014-07-17T01:01:48Z">
<saml:NameID SPNameQualifier="" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">_ce3d2948b4cf20146dee0a0b3dd6f69b6cf86f62d7</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2014-07-18T06:21:48Z" Recipient="" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/>
<saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2014-07-18T06:21:48Z">
<saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
<saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
<saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string"></saml:AttributeValue>
<saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>

Figure 2 SAML response

NotBefore & NotOnOrAfter in the subject element

In a SAML response, the Subject element has the SubjectConfirmation complex type. It specifies additional data that allows the subject to be confirmed, or constrains the circumstances under which the act of subject confirmation can take place.

In the SubjectConfirmation, Subject confirmation takes place when a relying party seeks to verify the relationship between an entity presenting the assertion and the subject of the assertion’s claims. SubjectConfirmation may includes attributes NotBefore and NotOnOrAfter.

NotBefore is a time instant before which the subject cannot be confirmed and NotOnOrAfter is a time instant at which the subject can no longer be confirmed.

NotBefore & NotOnOrAfter in the condition

The Condition element also may contain the attributes NotBefore and NotOnOrAfter. NotBefore specifies the earliest time instant at which the assertion is valid and NotOnOrAfter specifies the time instant at which the assertion has expired.

NotBefore, NotOnOrAfter problem 

As shown in Figure 3, both system clocks are not synced and IDP clock is 60 seconds faster than the SP clock:


Figure 3 System clocks

During this situation, if a SAML response is generated in the IDP, the response will contain a NotBefore time stamp which is 60 seconds greater than the SP time stamp. Therefore, when the assertion occurs in the SP with the SAML response, the assertion will fail since the SP time is less than NotBefore time.

But in the same scenario, if the network delay between IDP and the SP is more than 60 seconds, the response will reach the SP after the NotBefore time stamp, so the assertion will not fail.

In the second scenario (Figure 4), the IDP clock is 60 seconds slower than the SP clock, therefore the SAML response NotBefore time stamp is always less than the SP time stamp, and assertion will not fail due to the NotBefore condition.


Figure 4 Sytem clocks

However, if the SP has a response validity period of 100 seconds and the network delay between IDP and the SP is more than 40 seconds, the assertion will fail because of the NotOnOrAfter condition (Figure 5):

response validity period < IDP clock difference + network delay

Figure 5 Command


Even though ensuring the clocks are synchronized is one solution to this problem, it's not always a practical solution for dealing with inevitable small time drifts. Instead, the solution is to set the time stamp to allow for a small percentage of leeway to account for these naturally occurring time drifts. In that case, the SP is the consumer, so the SP system should be implemented with a clock skew.

 Note: Further information on synchronizing time with an external NTP server can be found here.