2

I am receiving SOAP requests with SAML AuthnStatements whose SessionNotOnOrAfter timestamp is EXACTLY the same value as its AuthnInstant:

<saml:AuthnStatement AuthnInstant="2020-04-22T21:11:41.453Z" SessionNotOnOrAfter="2020-04-22T21:11:41.453Z">

I am using ApacheWSS4J to validate the SOAP Signatures it also validates a variety of SAML 2.0 features including the AuthN statement. Messages which fit this pattern fail validation because as soon as I get the message it's AuthnStatement is instantly expired!

In order to either configure, or create my own validations I would like to learn about this condition through the lens of the SAML standard.

Does this condition represent an AuthN statement which is instantly invalid?

What does the SAML standard say, if anything, about a SessionNotOnOrAfter being exactly equal to AuthnInstant?

2

The definition of SessionNotOnOrAfter element in SAML Core is along the lines of what you'd expect. From section 2.7.2 on <AuthnStatement>:

SessionNotOnOrAfter [Optional]

Indicates an upper bound on sessions with the subject derived from the enclosing assertion. The time value is encoded in UTC, as described in Section 1.3.3. There is no required relationship between this attribute and a NotOnOrAfter condition attribute that may be present in the assertion. It's left to profiles to provide specific processing rules for relying parties based on this attribute.

Similarly, the definition of AuthnInstant in Core is pretty straightforward. In the same section 2.7.2:

AuthnInstant [Required]

Specifies the time at which the authentication took place. The time value is encoded in UTC, as described in Section 1.3.3.

Therefore from a perspective of validation of a SAML message as an XML document subject to certain rules described in Core portion of the SAML spec, the answers to your questions are:

Does this condition represent an AuthN statement which is instantly invalid?

Answer: no, it doesn't.

What does the SAML standard say, if anything, about a SessionNotOnOrAfter being exactly equal to AuthnInstant?

Answer: nothing

There are multiple kinds of rules and associated validation steps that may/should/must be performed by a relying party on a SAML message. The structural rules are described in the Core portion of the SAML spec but the behavioral rules are described in the Profiles.

In SAML a particular profile addresses how the assertions,protocols and bindings can be used in solving specific use cases. If the individual elements of SAML message are bricks, Core portion of SAML talks about shape, size and color of bricks whereas a particular profile in Profiles portion describes how to use the bricks to build a specific house. What is the right profile that would govern here?

While some SAML messages can be routed via SOAP over HTTP using rules documented and specified by the SOAP-specific bindings and appropriate profiles in SAML protocol, WSS4J is in a different ecosystem of standards. The behavior of WSS4J is governed by WS-Security. After all, WSS4J stands for Web Services Security for Java. In WS-Security, SAML tokens can be transmitted in a SOAP message based on an a profile of WS-Security rather than a profile of SAML. The appropriate WS-Security profile is WS-Security SAML Token Profile 1.1. Here's what it says about validating the SAML token embedded in a SAML message:

3.5 Subject Confirmation of SAML Assertions

Any processor of SAML assertions MUST conform to the required validation and processing rules defined in the corresponding SAML specification including the validation of assertion signatures, the processing of <saml:Condition> elements within assertions, and the processing of <saml2:SubjectConfirmationData> attributes. [SAMLCoreV1] defines the validation and processing rules for V1.1 assertions, while [SAMLCoreV2] is authoritative for V2.0 assertions.

Translation: the structural rules in SAML Core portion of SAML specification still apply. The behavioral rules are dictated by WS-Security SAML Token Profile and this profile does not mention anything with respect to SessionNotOnOrAfter or AuthnInstant.

| improve this answer | |
2

It's a misconfiguration on the partner's part.

And yes, it should absolutely fail validation. For two reasons:

  1. SessionNotOnOrAfter being equal to AuthInstant means that it is expired the instant the token is minted.
  2. When comparing SessionNotOnOrAfter to your system's time, since it's already expired, there's no way that has changed - the token is expired.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.