In the SAML2 specification there are several places in an assertion where it is possible to specify a lifetime.
<SubjectConfirmationData>
element contains a NotOnOrAfter
attribute.<Conditions>
element contains a NotOnOrAfter
attribute.<AuthnStatement>
element contains a SessionNotOnOrAfter
attribute.What is the meaning of each of them? How do they relate to each other?
Specifically, which of them must be checked when...
Each of the NotOnOrAfters are described in the SAML2 core specification. I've included the parts that I can find that describes these attributes here.
A time instant at which the subject can no longer be confirmed. The time value is encoded in UTC, as described in Section 1.3.3.
Note that the time period specified by the optional NotBefore and NotOnOrAfter attributes, if present, SHOULD fall within the overall assertion validity period as specified by the element's NotBefore and NotOnOrAfter attributes. If both attributes are present, the value for NotBefore MUST be less than (earlier than) the value for NotOnOrAfter.
Specifies the time instant at which the assertion has expired. The time value is encoded in UTC, as described in Section 1.3.3.
The NotBefore and NotOnOrAfter attributes specify time limits on the validity of the assertion within the context of its profile(s) of use. They do not guarantee that the statements in the assertion will be correct or accurate throughout the validity period. The NotBefore attribute specifies the time instant at which the validity interval begins. The NotOnOrAfter attribute specifies the time instant at which the validity interval has ended. If the value for either NotBefore or NotOnOrAfter is omitted, then it is considered unspecified. If the NotBefore attribute is unspecified (and if all other conditions that are supplied evaluate to Valid), then the assertion is Valid with respect to conditions at any time before the time instant specified by the NotOnOrAfter attribute. If the NotOnOrAfter attribute is unspecified (and if all other conditions that are supplied evaluate to Valid), the assertion is Valid with respect to conditions from the time instant specified by the NotBefore attribute with no expiry. If neither attribute is specified (and if any other conditions that are supplied evaluate to Valid), the assertion is Valid with respect to conditions at any time.
If both attributes are present, the value for NotBefore MUST be less than (earlier than) the value for NotOnOrAfter.
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.
I cross-posted this question to the SAML-dev mailing list and got an answer from Scott Cantor, who has been an editor on the specifications.
The times in the <SubjectConfirmationData>
signals for how long time assertion can be tied to the subject. In Web SSO where the subject confirmation method "bearer" is usually used, it means that within this time we can trust that the assertion applies to the one providing the assertion. The assertion might be valid for a longer time, but we must create a session within this time frame. This is described in the Web SSO Profile section 4.1.4.3. The times in <SubjectConfirmationData>
must fall within the interval of those in <Conditions>
.
The times in <Conditions>
is the validity of the entire assertion. It should not be consumed after this time. There is nothing preventing a user session on an SP to extend beyond this point in time though.
SessionNotOnOrAfter
is something completely different that is not directly related to the lifetime of the assertion or the subject. It is a parameter the idp can use to control how long an SP session may be. Please note that this parameter is defined that it SHOULD be handled by an SP according to the SAML2Core spec, but far from all SP implementations do. An example of an implementation that does is as usual Shibboleth, that always will respect the occurence of this parameter. When using Single Logout, this parameter is more critical, as it synchronizes the timeout of the session on both the SP and the Idp, to ensure that an SP does not issue a logout request for a session no longer known to the Idp.