zombie sessions

[IAM David Bantz]

But as the zombie session and the IdP logs demonstrate, the IdP uses
previous session to reply affirmatively to the SP's requests (which it
issues every 4 hours).
Here's processing of a request more than 24 hours after my authentication
with 0 user action or response:

14:41:29.753 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:209] -
> Processing incoming request
> 14:41:29.753 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:240] -
> Beginning user authentication process.
> 14:41:29.753 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:244] -
> Existing IdP session available for principal dabantz
> 14:41:29.753 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:283] -
> Filtering configured LoginHandlers:
> {urn:oasis:names:tc:SAML:2.0:ac:classes:Password=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler at 74c9a375,
> urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler at 74c9a375,
> urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler at 74c9a375,
>
> https://iam.alaska.edu/trac/wiki/mfa=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375,
> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler at 74c9a375
> }
> 14:41:29.753 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:347] -
> Filtering out previous session login handler because there are no active
> authentication methods
> 14:41:29.754 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:464] -
> Selecting appropriate login handler from filtered set
> {urn:oasis:names:tc:SAML:2.0:ac:classes:Password=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler at 74c9a375,
> urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler at 74c9a375,
>
> https://iam.alaska.edu/trac/wiki/mfa=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375,
> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler at 74c9a375
> }
> 14:41:29.754 - DEBUG
> [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:497] -
> Authenticating user with login handler of type
> edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler
> 14:41:29.754 - DEBUG
> [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler:91]
> - MCBConfiguration bean =
> [edu.internet2.middleware.assurance.mcb.authn.provider.MCBConfiguration at 1a2f9dd
> ]



[I'm testing this behavior - which replicates behavior reported by others -
using a client machine not using any other Shibb'd resources and using the
standby node of my IdP which thus has no other users.]
I just made an exception to that to re-affirm that there is a persistent
24+ hour old SSO session: I requested login to another service and was
authenticated via previous session - no request for credentials.]

Suggestions for tracking down what seems to be mis-behavior? The
appearance/visible effect is as though the periodic request from the SP
resets the timer for session expiration.

David Bantz


On Tue, Jun 14, 2016 at 2:55 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > That helps some, but the login handler authentication duration is
> allegedly
> > set to 8 hours as well:
>
> Then it would be limited to that. There is no question about it working,
> it's been like that forever.
>
> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20160614/32187972/attachment-0001.html>