We have a new SAML service provider partner that we are integration SAML 2.0 SSO with and they have a long list of requirements. One of their requirement is passing a SAML attribute which contains the value of the current timestamp of the assertion. I looked into our CA Directory server for a LDAP operation attribute that stores the current time/date that I can pull as a user attribute but there isn't such thing so I am hoping there is some other out of the box method to accomplishing this.
Thanks in advance for your suggestion and help.
Hmm timestamp for SAML 2.0 should just be part of the response already as the IssueInstant.
<Response xmlns="urn:oasis:names:tc:SAML:2.0:protocol" Destination="https://mysp.domain.com:443/acs" ID="_c7d6b3debc668c7b3df0309d6c7ed" InResponseTo="K156125e2s49i345hja007359" IssueInstant="2017-05-15T21:45:23Z" Version="2.0">
Additionally as part of the authnstatement they can have the authninstant as well.
<ns2:AuthnStatement AuthnInstant="2017-05-15T21:48:45Z" SessionIndex="/GPcy1iUSFlXHiO59a83o=MA==" SessionNotOnOrAfter="2017-05-15T22:48:45Z">
And the Conditions NotBefore or NotOnOrAfter should give guidance on the total length of validity of the assertion itself with configurable skews.
<ns2:Conditions NotBefore="2017-05-15T21:48:16Z" NotOnOrAfter="2017-05-15T21:50:16Z">
Thanks for the response. This is what I was trying to explain to our SAML service provider partner, but whomever prepared their SAML implementation document had this requirement and they are sticking with it, which makes no sense but will probably require us to do some customization with the SiteMinder Assertion Generator plugin to accomplish this.
Tell the Service Provider to act right lol...SAML solved most of the time stamping considerations. Out of the hundreds of Service Providers I've ever worked with, none of them have ever required the timestamp in that sense to be in an assertion O_o.
Never tried it but might could leverage some of the "DATE/TIME" Named Expression stuff - Operators - CA Single Sign-On - 12.7 - CA Technologies Documentation . Can set those up so they can be returned as an attribute perhaps and send along.
Maybe someone else has some other ideas.
But it's really silly for the Service Provider to demand something like that when everything regarding the time assertion was issued, user auth time, assertion validity, optionally recommended session duration, etc is all already present with clear definitions of their meanings. To strictly require it as an attribute statement just doesn't sit right : / .
==== EDIT ====
Would have to pretty it up, but named expression does seem to work ok. You'd want to adjust it of course to what format and timezone or whatever. Just added something like this as a rough little test:
Gives this value.
<ns2:AttributeStatement> <ns2:Attribute Name="timestamp" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified" > <ns2:AttributeValue>16/05/17/13:13:37</ns2:AttributeValue> </ns2:Attribute>