[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Potential Errata: Core description of SessionNotOnOrAfter insufficient?
I was having a conversation recently with some EMC
developers re: managing session timeouts at SP’s. They are new to
SAML and as a result of the conversation, it occurred to me that the phrasing in
the Core spec around the use of the SessionNotOnOrAfter attribute of an AuthnStatement
is perhaps a bit insufficient. They were mistaken by interpreting the attribute
to mean that it only pertained to the user session at the IdP and that its
presence in an AuthnStatement meant nothing about the session at the SP. The
Core spec states: SessionNotOnOrAfter [Optional] Specifies a time instant at which
the session between the principal identified by the subject and the SAML authority issuing this
statement MUST be considered ended. 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. While the first sentence is, of course, true, it is limited
to the session at the issuing authority. I think we should also say something
about how relying parties should treat this attribute when it is received.
I pointed the developers to the SSO profile, which elaborates on its meaning (at
least for that profile). In the redlined profile spec, the processing of
a <Response> message by a Relying Party includes: If an <AuthnStatement>
used to establish
a security context for the principal contains a SessionNotOnOrAfter
attribute,
the security context SHOULD be discarded once this time is reached, unless the service
provider reestablishes the principal's identity by repeating the use of this profile. Note that if multiple <AuthnStatement>
elements are
present, the SessionNotOnOrAfter value closest to the present time SHOULD be honored. Throughout the core spec, we often describe how an element
or attribute should be treated by a relying party if it is present. This might
be processing rules that 1) apply to all profiles, 2) apply to all profiles
unless specifically overridden by a profile, or 3) are completely defined by a
profile of use. I believe our intention for this attribute was that if it is
present in an assertion, then a relying party should not maintain a session for
the user beyond that time since the IdP no longer considers it valid.
However, it might also be argued that its interpretation should be potentially
overridden by a profile or be strictly profile-defined. I can live with
any of these, but want to suggest that we add some appropriate text for this
attribute in core w.r.t. how an RP should interpret it. I’m interested in hearing what others think about this… Rob Philpott RSA, the
Security Division of EMC |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]