Forced reauthentication

[Cantor, Scott]

On 8/14/14, 7:30 PM, "Jesse Santana" <Jesse.Santana at csulb.edu> wrote:

>The entire log entry looks like this:
>
>2014-08-14 16:27:53 INFO Shibboleth-TRANSACTION [3]: New session (ID:
>_e334e3c4ba1911df55847a371825edec) with (applicationId: default) for
>principal from (IdP: http://www.okta.com/kv79fg77CWVTMIVZXMLF) at
>(ClientAddress: 134.139.2.14) with (NameIdentifier: 000020564) using
>(Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID:
>id37166912858056794557589990)
>
>Which does get updated when I go to the application again:
>
>2014-08-14 16:29:11 INFO Shibboleth-TRANSACTION [5]: New session (ID:
>_e3f18b546f6524bb64232d748c9d62ca) with (applicationId: default) for
>principal from (IdP: http://www.okta.com/kv79fg77CWVTMIVZXMLF) at
>(ClientAddress: 134.139.2.14) with (NameIdentifier: 000020564) using
>(Protocol: urn:oasis:names:tc:SAML:2.0:protocol) from (AssertionID:
>id377649452240692491450287841)

That's a bit odd frankly, I don't know why you're getting a new session at
all from opening a new tab, but assuming you are, then the IdP in question
is ignoring the ForceAuthn setting. If so, it's doubly broken in that it's
also apparently lying about the authentication timestamp.

Cue Eric Goodman. ;-)

It's probably worth tracing the messages and actually verifying what
you're requesting and what they're sending.

You can't set the SP's session lifetime to 5 seconds, that would be
pathological unless you're not using the session locally for anything
after it's created.

-- Scott