SAML assertion could not be validated error

The error displayed in Figure 1 could be caused by an expired certificate:

 

2.png

Figure 1 Error

 

If the certificate hasn't already expired, it may be due to expire within two weeks. ADFS invalidates any primary or secondary certificates expiring within two weeks. More information on this rollover period 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. A sample SAML response is given below (Figure 2):

3.png

<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="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685">
<saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" ID="_d71a3a8e9fcc45c9e9d248ef7049393fc8f04e5f75" Version="2.0" IssueInstant="2014-07-17T01:01:48Z">
<saml:Issuer>http://idp.example.com/metadata.php</saml:Issuer>
<saml:Subject>
<saml:NameID SPNameQualifier="http://sp.example.com/demo1/metadata.php" 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="http://sp.example.com/demo1/index.php?acs" InResponseTo="ONELOGIN_4fee3b046395c4e751011e97f8900b5273d56685"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2014-07-17T01:01:18Z" NotOnOrAfter="2014-07-18T06:21:48Z">
<saml:AudienceRestriction>
<saml:Audience>http://sp.example.com/demo1/metadata.php</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2014-07-17T01:01:48Z" SessionNotOnOrAfter="2024-07-17T09:01:48Z" SessionIndex="_be9967abd904ddcae3c0eb4189adbe3f71e327cf93">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<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>
<saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
</saml:Attribute>
<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>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>

Figure 2 SAML Response

 

NotBefore & NotOnOrAfter in Subject

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 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:

mceclip1.png

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.

 mceclip2.png

Figure 4 Sytem Clocks

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.

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:

response validity period < IDP clock difference + network delay

 

Resolution

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 can be found here