SAML assertion is rejected by SP because of timestamp on AuthnStatement AuthnInstant is too old

[Naveen A]

Hello All,

 

we are using CA SiteMinder as our IDP for our federations. we use siteminder web agent option pack in our IDP environment. For a particular partnership SAML assertions that were sent to SP by our IDP are getting rejected because of AuthnStatement AuthnInstant is tool old. This particular SAML assertion is generated on 07/17/2018 13:59:27 but the timestamp of AuthnStatement AuthnInstant is set to 07/03/2018 14:58:27. we are not sure why AuthnStatement AuthnInstant timestamp is set that way. 

 

<ns2:AuthnStatement AuthnInstant="2018-07-03T14:58:27Z" SessionIndex="pII5eRFB8NEiOVlQLQaHJMa+pvk=XNhWIw==" SessionNotOnOrAfter="2018-07-18T17:59:57Z">
<ns2:AuthnContext>
<ns2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</ns2:AuthnContextClassRef>
</ns2:AuthnContext>
</ns2:AuthnStatement>

 

When we try accessing the same partnership in a "New Browser Session" it setting the actual access timestamp on AuthnStatement AuthnInstant and SP is able to consume the assertion. But when we try to access the same partnership in a "New window" or "New Tab" we ending up with timestamp  of AuthnStatement AuthnInstant is set to 07/03/2018 14:58:27. we tried clearing all cookies, browsing history and Cache from the browser and even tried close the browser and re-open it. But we still having the issue.

 

Any thoughts?

 

Environment:

SM WAOP : 12.50

SMPS: 12.52 SP1 CR06

 

Thank you,

Naveen

[emmle02]

Hi Naveen,

 

Refer : SAML IssueInstant and AuthnInstant 

 

http://docs.oasis-open.org/security/saml/Post2.0/saml-session-token/v1.0/csd01/saml-session-token-v1.0-csd01.html

 it mentioned:

 

AuthnInstant [Required]

The SA MUST set the AuthnInstant to the time authentication occurred, as defined in [SAML2Core]. The SC MAY use this value to implement a maximum login time.

 

 

Regards,

Leo Joseph.

[Naveen A]

Hi Leo,

 

According to SAML documentation, SA represents Session Authority and SC represents Session consumer. In our case we are IDP and using CA SiteMinder and a third party vendor is acting a SP. So according to me SA=IDP and SC=SP. Correct me if i am wrong.

 

Thank you,

Naveen

[Donal Hunt]

Hi Naveen,

Did you get sorted with your AuthnInstant issue?

The behaviour you are seeing is expected but experience of implementations is hit and miss due to Service Providers (SP in SAML speak) typically expecting the AuthnInstant to be recent and many Identity Providers (IdP in SAML speak) reducing the amount of authentication actions end users have to complete.

In the case of Microsoft's and Google's SAML implementations, they will continue to send assertions even if the last Authentication by the user was hours (or even days) ago. Microsoft allow admins to set a per-SP policy to align the IdP's policy with the SP's expectations. Google allows you to configure the session length but it affects all properties (incl gmail, calendar, etc)

For CA SiteMinder, it's not clear if there is a way to reduce the session token validity for the IdP (I'm not familiar with the product). If not, the two options you have are to allow AuthnInstant to be valid for longer (set on the SP side) or see if the SP has the ability to set the ForceAuthn value on the SAMLrequest to the IdP (will only work if CA siteminder respects the ForceAuthn option in the SAML spec).