OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [saml-dev] NotOnOrAfter in SubjectConfirmationData and Conditions and SessionNotOnOrAfter


Thank you Scott,


Things are getting a bit more clear to me. I would just like to confirm that in the context of the WebSSO profile I've understood it correctly.


* The SubjectConfirmationData/@NotOnOrAfter attribute is the time window during which the assertion can be tied to the subject. If the SP establishes a session, it must be done within this time frame (Web SSO Profile 4.1.4.3), but the session can continue long after that time.

* The Conditions/@NotOnOrAfter attribute is the longest possibility to trust the information in the assertion. During this time it is possible to forward the Assertion to another service to act on behalf of that (such as an SP calling a backend SOAP service).

* The SessionNotOnOrAfter sets an absolute limit to the SP session.

 

Is that correct?

 

One thing is still unclear to me though, and it is the relation between Conditions/@NotOnOrAfter and SessionNotOnOrAfter. In core (section 2.4.1.2) it is clearly stated that the time frame in SubjectConfirmationData should fall within the time frame in the Conditions. But I can't find anything related to SessionNotOnOrAfter. Could SessionNotOnOrAfter be a later point in time than Conditions/@NotOnOrAfter, as long as the SP doesn't trust the attributes after the Conditions/@NotOnOrAfter has passed. That could be the case if the establishment of an SP session solely depends on the Subject NameId.

 

Best Regards,

Anders



Den den 10 april 2015 klockan 19:45 skrev "Cantor, Scott" <cantor.2@osu.edu>:

> On 4/10/15, 5:16 AM, "Anders Abel" <anders@abel.nu> wrote:
>
> >Hello,
> >
> >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?
>
> The Conditions window addresses general validity of an assertion, and validity is described at length in core.
>
> The SubjectConfirmation's validity applies solely to the window during which it's possible to confirm the subject's right to use the assertion in a particular manner. SubjectConfirmation is what turns a SAML assertion (data) into a security token that gets used to authenticate some party in an application. So it limits when the token has security semantics in a particular way.
>
> SessionNotOnOrAfter is about IdPs limiting session lifetime at an SP when a session is based on the authentication statement.
>
> >
> >Specifically, which of them must be checked when...
>
> The requirements in core are invariant. You CANNOT accept an assertion as valid if the Conditions aren't valid, and you CANNOT apply a SubjectConfirmation evaluation to one that has expired. Beyond that, it's a profile consideration and which values are expected to be used is something the profile should speak to. The SSO profile does speak to them.
>
>
> -- Scott
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]