Shibboleth SP 3 and SubjectConfirmation NotOnOrAfter seems to be ignored

[Michael Nielsen]

I would be grateful if someone could please help me understand the behavior of the Service Provider that I shall describe below.

I'm sure it's due to some gap in my understanding of SAML, but I have been trying to fill that gap for several days now and have not had any success.

I have an application whose frequent XHR requests hit a Shibboleth-protected endpoint.

The IdP (ADFS) is providing this Subject and Conditions in its assertion:


          <Subject>

            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><SubjectConfirmationData InResponseTo="_919647393007bfbe7252284cf3f475d4"

                NotOnOrAfter="2018-10-18T21:13:53.932Z"

                Recipient="https://my.serviceProvder.com/Shibboleth.sso/SAML2/POST"/></SubjectConfirmation>

        </Subject>

        <Conditions NotBefore="2018-10-18T21:08:53.929Z" NotOnOrAfter="2018-10-19T05:08:53.929Z">

            <AudienceRestriction>

                <Audience>https://my.serviceProvder.com/shibboleth</Audience>

            </AudienceRestriction>

        </Conditions>

In particular, observe the SubjectConfirmation NotOnOrAfter is about 5 minutes after the time of issue of the assertion (see the Conditions NotBefore).

The behavior of the Shibboleth 3 Service Provider (shibboleth-3.0.1-3.1.x86_64) is as follows:

If the user starts using the application before the SubjectConfirmation's NotOnOrAfter and continues to use the application (thereby issuing XHR requests to the Shibboleth-protected endpoint), XHR requests are not 302'd by Shibboleth back to the IdP even after the SubjectConfirmation's NotOnOrAfter.

However, if the user pauses the stream of XHR requests for some number of minutes (5, as nearly as I can tell) after the SubjectConfirmation's NotOnOrAfter, then subsequent requests are 302'd back to the IdP.

Under what circumstances does Shibboleth SP (apparently) not observe the SubjectConfirmation's NotOnOrAfter?

What mechanism determines the number of idle minutes?

I'm using a lifetime="28800"  timeout="1800" and relayState="cookie" in my Sessions for this particular IdP, if that matters.

My SessionCache uses my MEMCACHE storage service and specifies a CacheAllowance of 3600, with default cleanupInterval and inprocTimeout.

Many thanks for any help you can offer!

Regards,

Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20181019/208995be/attachment.html>