In the SAML2 specification there are several places in an assertion where it is possible to specify a lifetime. <ul> <li>The <code><SubjectConfirmationData></code> element contains a <code>NotOnOrAfter</code> attribute.</li> <li>The <code><Conditions></code> element contains a <code>NotOnOrAfter</code> attribute.</li> <li>The <code><AuthnStatement></code> element contains a <code>SessionNotOnOrAfter</code> attribute.</li> </ul> What is the meaning of each of them? How do they relate to each other? Specifically, which of them must be checked when... <ul> <li>... consuming an incoming Saml2Response using Web SSO</li> <li>... establishing an application session in the SP</li> <li>... refreshing (extending) an application session in the SP</li> <li>... forwarding an assertion to a web service, to act on behalf of the subject (as described by @Thuan)</li> <li>... issuing a single logout request to the idp, to ensure that the idp still knows of the session?</li> </ul> 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. <h3>SubjectConfirmationData/@NotOnOrAfter</h3> <blockquote> 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. </blockquote> <h3>Conditions/@NotOnOrAfter</h3> <blockquote> 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. </blockquote> <h3>AuthnStatement/@SessionNotOnOrAfter</h3> <blockquote> 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. </blockquote>

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. <ul> <li>The times in the <code><SubjectConfirmationData></code> 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 <code><SubjectConfirmationData></code> must fall within the interval of those in <code><Conditions></code>.</li> <li>The times in <code><Conditions></code> 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.</li> <li><code>SessionNotOnOrAfter</code> 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.</li> </ul>

In my opinion, only the authors of Saml2 specification can clearly answer this question. I also guess they can write a 10000-page book to explain about many "why" questions about the spec that people have asked for years. Anyway, based on my limited knowledge and on the use cases I have experienced with, my interpretation of those properties is: Let's look at an example: <ol> <li>SSO: An SP receives an assertion from an IdP and log the user on.</li> <li>Bootstrap token: The SP saves the assertion as a bootstrap token for later use.</li> <li>The SP uses the bootstrap token to exchange for an ActAs token so that it can be used to access another web service. It will also cache the token for further uses to avoid having to exchange a new token often, as long as that token is still valid.</li> </ol> For (1), an assertion is valid when and only when both SubjectConfirmationData.NotOnOrAfter and Conditions.NotOnOrAfter are valid. Since the assertion is valid, the SP will create a login session for the user. How long the session should be is specified by the SessionNotOnOrAfter value. How about 3? I would say the token is considered valid when Conditions.NotOnOrAfter is still valid. According to Scott Cantor: "Processing rules are specific to profiles and the context of use." Source: https://lists.internet2.edu/sympa/arc/mace-opensaml-users/2011-05/msg00007.html In that link they also discussed about the lifetimes of Subject and Conditions in which Conditions usually has longer lifetime than that of the Subject.

NotOnOrAfter in SubjectConfirmationData and Conditions and SessionNotOnOrAfter

In the SAML2 specification there are several places in an assertion where it is possible to specify a lifetime.

The <SubjectConfirmationData> element contains a NotOnOrAfter attribute.
The <Conditions> element contains a NotOnOrAfter attribute.
The <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...

... consuming an incoming Saml2Response using Web SSO
... establishing an application session in the SP
... refreshing (extending) an application session in the SP
... forwarding an assertion to a web service, to act on behalf of the subject (as described by @Thuan)
... issuing a single logout request to the idp, to ensure that the idp still knows of the session?

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.

SubjectConfirmationData/@NotOnOrAfter

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.

Conditions/@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.

AuthnStatement/@SessionNotOnOrAfter

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.

What is NotOnOrAfter in SAML?

Conditions/@NotOnOrAfterSpecifies 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.

How long is SAML assertion valid?

Saml response has a token lifetime of 1 hour for SAML token or it is valid till the certificate used for sign in is valid.

What is SAML recipient?

Recipient is associated with the Subject element of SAML Assertion, which is about the user or subject for which the authentication is performed and that Subject data is awarded by IdP to that particular Recipient (the SP), who can act on the Assertion.

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.

In my opinion, only the authors of Saml2 specification can clearly answer this question. I also guess they can write a 10000-page book to explain about many "why" questions about the spec that people have asked for years. Anyway, based on my limited knowledge and on the use cases I have experienced with, my interpretation of those properties is:

Let's look at an example:

SSO: An SP receives an assertion from an IdP and log the user on.
Bootstrap token: The SP saves the assertion as a bootstrap token for later use.
The SP uses the bootstrap token to exchange for an ActAs token so that it can be used to access another web service. It will also cache the token for further uses to avoid having to exchange a new token often, as long as that token is still valid.

For (1), an assertion is valid when and only when both SubjectConfirmationData.NotOnOrAfter and Conditions.NotOnOrAfter are valid. Since the assertion is valid, the SP will create a login session for the user. How long the session should be is specified by the SessionNotOnOrAfter value.

How about 3? I would say the token is considered valid when Conditions.NotOnOrAfter is still valid. According to Scott Cantor: "Processing rules are specific to profiles and the context of use." Source: https://lists.internet2.edu/sympa/arc/mace-opensaml-users/2011-05/msg00007.html In that link they also discussed about the lifetimes of Subject and Conditions in which Conditions usually has longer lifetime than that of the Subject.

NotOnOrAfter in SubjectConfirmationData and Conditions and SessionNotOnOrAfter