SAML 2.0 assertion expiry vs. session duration

[Hans Zandbelt]

Hi,

In the current simpleSAMLphp implementation there is a configuration
option called "session.duration". This propagates into the
SAML 2.0 authentication response element "saml:Conditions"
as the "NotOnOrAfter" attribute value.

Reading the SAML 2.0 spec saml-core-2.0-os, it says in section 2.5.1
(page 21), about the NonOnOrAfter setting in the Conditions element:

NotOnOrAfter [Optional]
Specifies the time instant at which the assertion has expired.

This suggests that is is about the assertion lifetime instead of
the session lifetime. There is another attribute called
"SessionNotOnOrAfter" (section 2.7, page 27), part of the AuthnStatement,
that is supposed to reflect the session lifetime, more in line with
the variable naming and comments about the SSP "session.duration" setting.

My feeling is that at least the session.duration setting is wrongly
translated into the saml:Conditions. Do you agree and should this be
corrected?

Regards,

Hans.

--
Hans Zandbelt hans.z...@surfnet.nl
SURFnet http://www.surfnet.nl

[Olav Morken]

There are three different expiration timestamps that can be set in an
authentication response (that I am aware of):
- Subject/SubjectConfirmation/SubjectConfirmationData@NotOnOrAfter
- Conditions@NotOnOrAfter
- AuthnStatement@SessionNotOnOrAfter

Each of these deals with the lifetime of one part of the assertion.
Here is my interpretaion of each of them:

The one in the SubjectConfirmation-element indicates how long we can
identify the subject of the assertion.

The one on the Conditions-element specifiy how long the assertion itself
is valid. The question here is: When is the assertion used? Every time
you use attributes received from it, or only once - when you extract
the attributes from it?

I think that the AuthnStatement deals with the users "authentication
session" on the IdP. It contains timestamp for when the user was
authenticated, the method of authentication and the users session index
on the IdP. I therefore interpret this to mean "how long is the users
session valid on this IdP".

I am not certain what values we should store in the various places, but
I think that the goal should be to maximize interoperability. The
current values seem to work, and I am therefore hesitant to change any
of these values without knowing what the result will be.

What values do you want to store in the various locations?

--
Olav Morken

[Hans Zandbelt]

Hi Olav,

Olav Morken wrote, On 23/07/09 16:33:

Well, actually they do not, and that is the reason fro bringing this up.
Since r1395 the default changed from 1 hour to 8 hours (ie. from the
hard-coded default to the default from config.php) and as it appears only
now, this gives problems with the default settings in PingFederate which
thinks this value is too high to accept (at least by default):

http://code.google.com/p/simplesamlphp/source/diff?spec=svn1312&old=1312&r=1395&format=side&path=%2Ftrunk%2Fwww%2Fsaml2%2Fidp%2FSSOService.php

> of these values without knowing what the result will be.
>
>
> What values do you want to store in the various locations?

I'd vote for, setting the first two:

- Subject/SubjectConfirmation/SubjectConfirmationData@NotOnOrAfter
- Conditions@NotOnOrAfter

equal, to a short period, being the period that the assertion
is still valid for consumption (I think using values from an
already received&consumed assertion is out of scope). NB: a
long setting as it is now has security implications since it
increases vulnerability to replay attacks.

Then:
- AuthnStatement@SessionNotOnOrAfter
is for session duration, ie. it indicates the validity period
for the session at the IDP.

This is equal to your interpretation, and I think the implementation
should adhere to the spirit of the spec rather than trying to address
(yet-unproven) interoperability issues.
("Be strict in what you send, but generous in what you receive")

[Olav Morken]

That changes the situation! Though I am suprised that some software has
a _maximum_ lifetime of an assertion.

> > of these values without knowing what the result will be.
> >
> >
> > What values do you want to store in the various locations?
>
> I'd vote for, setting the first two:
>
> - Subject/SubjectConfirmation/SubjectConfirmationData@NotOnOrAfter
> - Conditions@NotOnOrAfter
>
> equal, to a short period, being the period that the assertion
> is still valid for consumption (I think using values from an
> already received&consumed assertion is out of scope). NB: a
> long setting as it is now has security implications since it
> increases vulnerability to replay attacks.

The specification says that it is the NotOnOrAfter attribute of the
SubjectConfirmationData-element that should be used for this purpose.

> Then:
> - AuthnStatement@SessionNotOnOrAfter
> is for session duration, ie. it indicates the validity period
> for the session at the IDP.
>
> This is equal to your interpretation, and I think the implementation
> should adhere to the spirit of the spec rather than trying to address
> (yet-unproven) interoperability issues.
> ("Be strict in what you send, but generous in what you receive")

I don't see anything about the maximum assertion lifetime in the spec?
And I would say that in this case PingFederate, it fails the second part
of that sentence.

But: I have looked at the Shibboleth IdP, as it seems that in the world
of SAML(2), doing what Shibboleth does is the way to maximize
interoperability. And Shibboleth has a "tunable" (assertionLifetime),
which defaults to 300 seconds, so I think that is the way to go. That
value is usef for both the Conditions and the SubjectConfirmationData
elements.

This behaviour is (I assume) exactly what you want? I just wish that
it was documented somewhere. For me at least, the intuitive
interpretation of the Conditions-element is that it specifies the
period of time the contents of the Assertion can be considered valid,
and that after that time has passed, the SP should ask the IdP for a
new Assertion...

--
Olav Morken

[Hans Zandbelt]

Hi Olav,

Olav Morken wrote, On 24/07/09 09:21:

>>> What values do you want to store in the various locations?
>> I'd vote for, setting the first two:
>>
>> - Subject/SubjectConfirmation/SubjectConfirmationData@NotOnOrAfter
>> - Conditions@NotOnOrAfter
>>
>> equal, to a short period, being the period that the assertion
>> is still valid for consumption (I think using values from an
>> already received&consumed assertion is out of scope). NB: a
>> long setting as it is now has security implications since it
>> increases vulnerability to replay attacks.
>
> The specification says that it is the NotOnOrAfter attribute of the
> SubjectConfirmationData-element that should be used for this purpose.
>
>> Then:
>> - AuthnStatement@SessionNotOnOrAfter
>> is for session duration, ie. it indicates the validity period
>> for the session at the IDP.
>>
>> This is equal to your interpretation, and I think the implementation
>> should adhere to the spirit of the spec rather than trying to address
>> (yet-unproven) interoperability issues.
>> ("Be strict in what you send, but generous in what you receive")
>
> I don't see anything about the maximum assertion lifetime in the spec?
> And I would say that in this case PingFederate, it fails the second part
> of that sentence.

Exactly, and SSP can do better :-)

> But: I have looked at the Shibboleth IdP, as it seems that in the world
> of SAML(2), doing what Shibboleth does is the way to maximize
> interoperability. And Shibboleth has a "tunable" (assertionLifetime),
> which defaults to 300 seconds, so I think that is the way to go. That
> value is usef for both the Conditions and the SubjectConfirmationData
> elements.
>
> This behaviour is (I assume) exactly what you want? I just wish that

Yes; I think this requires some settings/variable renaming in SSP as well,
to better reflect the actual semantics.

> it was documented somewhere. For me at least, the intuitive
> interpretation of the Conditions-element is that it specifies the
> period of time the contents of the Assertion can be considered valid,
> and that after that time has passed, the SP should ask the IdP for a
> new Assertion...

I think the conditions are merely about the validity period for
_receiving_ an assertion. But I agree that it is not really clear from
the spec.

Thanks,

[Olav Morken]

I am working on replacing the lib/SimpleSAML/XML/SAML20/* classes with
new classes, and I can add it while working on those. Basically, I'm
thinking something like setSessionNotOnOrAfter() for the session part
and setNotOnOrAfter() for the other two.