Forum Discussion
SAML SSO - NotBefore Tag?
We're seeing an issue with one of our external SAML SSO SP partners where they require strict adherence to the "NotBefore" attribute in the assertion that's being sent by our IdP.
This value appears to be set identically to the IssueInstant value, and unfortunately I don't see a way to manually set this value. I do have an option to set the NotOnOrAfter value, but unfortunately this doesn't help me. We're running on 11.3 currently.
Thoughts? Are there options to change this value in 11.3?
4 Replies
Sorry, I am not clear as to what the issue is. When you say strict adherence, what is APM not doing properly to appease the External SAML SP?
- AJ_01_135899
Cirrostratus
The issue is that the SP's system time is several seconds before our IdP's system time, causing a failure on their side since the assertion IssueInstant (and thusly NotBefore) time is before their system time at the time the assertion is received.
This NotBefore time is not configurable on our side like the NotOnOrAfter time is - the NotBefore value contained in the assertion is exactly the same as the IssueInstant.
I mention adherence only because either our other (working) SPs have system times that happen to be after our system time, or they do not strictly adhere to the NotBefore value in the assertion.
- Kevin_Stewart
Employee
That's an interesting observation, and unfortunately I don't believe there is a way to alter the NotBefore value. I'd offer up the following suggestions:
-
Coordinate time between sites. I'm surprised that someone isn't already having issues with time, given its criticality within other protocols and functions in a typical datacenter. UTC time sources are abundant, so there's rarely a reason not to be in sync.
-
Contact support and open a case. Indeed, the Oasis specification doesn't make any mention of dependencies between IssueInstant and NotBefore, and I've seen examples of them being different.
-
- AJ_01_135899
Cirrostratus
UTC time sources are indeed abundant, yet certainly there should always be allowances for variation - this could be an issue even if there is drift in the milliseconds.
It looks like this was fixed in 11.4.1 HF4:
http://support.f5.com/kb/en-us/solutions/public/14000/800/sol14835.html
ID 433243 : BIG-IP IdP subtracts three minutes from assertion's NotBefore timestamp to accomodate SPs whose clocks may be behind.
I appreciate the responses.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com
