AuthnInstant occurs in future after current time

Products

SITEMINDER CA BCS Premier for CA Single Sign-On CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On

Issue/Introduction

After upgraded from 12.8sp2 to 12.8sp7, a particular federation IDP stops working. However, other partnerships work fine.

This particular federation idp was working fine prior the upgrade.

Policy server trace says:

[mm/dd/yyyy][hh:mm:ss.000][hh:mm:ss][Pid][Tid][SmAuthSaml.cpp:1324][SmAuthenticate][][][][][][][][][][][][][][][][][][][][][lpArray[1]=Assertion rejected (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx) - AuthnInstant (Tue MM 23 21:46:11 EST YYYY) occurs in future after current time {Tue MM 23 16:48:13 EST YYYY) SAML20: failed to find acceptable assertion in Response message]

Environment

Policy server version : Upgrade from 12.8 SP2 to 12.8 SP7

Cause

AuthnInstant time is always in GMT time zone when comes in from IDP.

SP does not change its value, only compares it and proceeds on the result.

If SiteMinder is SP, only receiving the assertion content, AuthnInstant value will only show up in policy server side smtracedefault.log.

In non-working scenario, AuthnInstant time did not get time zone conversion on 12.8sp7

AuthnInstant="yyyy-mm-28T18:51:18.028014" ....becomes ...... (before skew) = Wed mm 28 18:51:18 EST yyyy

In working scenario, time zone conversion is conducted on the AuthnInstant time stamp.

AuthnInstant="yyyy-mm-26T15:58:16.677Z" ....becomes ...... (before skew) = Mon mm 26 10:58:16 EST yyyy

This results to all transaction falls outside of skew time window (60 seconds), unless skew time was increased to cover entire 5 more hours.

The failure was due to particular IDP partner sends in assertion with unusual parameter value. e.g. AuthnInstant="yyyy-mm-ddT18:51:18.028014", which is in microseconds format.

12.8sp7 policy server did not do time zone conversion on AuthnInstant value, due to microseconds format.

According to saml 2 specification, "All SAML time values have the type xs:dateTime, which is built in to the W3C XML Schema Datatypes specification [Schema2], and MUST be expressed in UTC form, with no time zone component. SAML system entities SHOULD NOT rely on time resolution finer than milliseconds. Implementations MUST NOT generate time instants that specify leap seconds."

Resolution

There was a change in how AuthnInstant was processed between version 12.8sp2 vs 12.8sp7.

However, the change SiteMinder made still adheres to SAML2 specification. That's why other partnerships still work.

The failure was due to the particular IDP partner sends in assertion with unusual parameter value AuthnInstant="yyyy-mm-ddT18:51:18.028014", which is in microseconds format.

The recommended solution is asking IDP partner to change its time stamp format to something like "yyyy-mm-26T15:58:16.677Z".