<div dir="ltr">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).<div>Here's processing of a request more than 24 hours after my authentication with 0 user action or response:</div><div><br></div><div>







<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">14:41:29.753 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:209] - Processing incoming request<br></span><span class="">14:41:29.753 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:240] - Beginning user authentication process.<br></span><span class="">14:41:29.753 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:244] - Existing IdP session available for principal dabantz<br></span><span class="">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@74c9a375, urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375, urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375, <a href="https://iam.alaska.edu/trac/wiki/mfa=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375">https://iam.alaska.edu/trac/wiki/mfa=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375</a>, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375}<br></span><span class="">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<br></span><span class="">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@74c9a375, urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375, <a href="https://iam.alaska.edu/trac/wiki/mfa=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375">https://iam.alaska.edu/trac/wiki/mfa=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375</a>, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler@74c9a375}<br></span><span class="">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<br></span><span class="">14:41:29.754 - DEBUG [edu.internet2.middleware.assurance.mcb.authn.provider.MCBLoginHandler:91] - MCBConfiguration bean = [edu.internet2.middleware.assurance.mcb.authn.provider.MCBConfiguration@1a2f9dd]</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"> </blockquote><div>[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.]</div><div>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.]</div><div> </div><div>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.</div><div><br></div><div>David Bantz</div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 2:55 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> That helps some, but the login handler authentication duration is allegedly<br>
> set to 8 hours as well:<br>
<br>
</span>Then it would be limited to that. There is no question about it working, it's been like that forever.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>