How are the SPConfig clockSkew attribute and a Conditions NotBefore related?

Brian Reindel giantjamsandwich at gmail.com
Mon Jun 23 12:50:26 EDT 2014


It appears that the session is being created and then removed. I see
this in the logs:

2014-06-23 10:54:55 DEBUG XMLTooling.StorageService [2]: inserted
record (session) in context (_61fe23d4a78c08e9fdaad5580931ca65) with
expiration (1403538895)
...
2014-06-23 10:54:55 INFO Shibboleth.SessionCache [2]: new session
created: ID (_61fe23d4a78c08e9fdaad5580931ca65) IdP ([redacted url])
Protocol(urn:oasis:names:tc:SAML:2.0:protocol) Address ([redacted IP])
...
2014-06-23 10:54:55 DEBUG XMLTooling.StorageService [3]: updated
expiration of valid records in context
(_61fe23d4a78c08e9fdaad5580931ca65) to (1403538895)
...
2014-06-23 10:54:55 INFO Shibboleth.SessionCache [3]: removed session
(_61fe23d4a78c08e9fdaad5580931ca65)

This is the conditions node from the assertion that comes back:

<Conditions NotBefore="2014-06-23T14:55:23.501Z"
NotOnOrAfter="2014-06-23T15:55:23.501Z">

The clock time in the log (zone of America/New_York) is 2014-06-23
10:54:55. You can see there is about a 30 second lag after accounting
for the Identity Provider's time zone. The clock time is in the past.
I'm in a phase now where I'm looking for options to eliminate the
discrepancy if at all possible within the service provider.


On Mon, Jun 23, 2014 at 11:57 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:
> On 6/23/14, 11:54 AM, "Brian Reindel" <giantjamsandwich at gmail.com> wrote:
>
>>We're having issues where a third party identity provider on Windows
>>is setting the NotBefore correctly, but our CentOS box that has our
>>service provider is 30 seconds in the past. The session is expiring
>>immediately as a result. I thought the clockSkew would take care of
>>this discrepancy, and it is set to the default of 180. Am I
>>misunderstanding how clockSkew works?
>
> A session wouldn't expire, it wouldn't be created to begin with. They
> might be setting SessionNotOnOrAfter, and that doesn't quite have the same
> allowance for skew because of how it works.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list