Logout Issue

Oak, Joe Joe.Oak at StateAuto.com
Wed Aug 19 08:17:11 EDT 2015

Ok, thanks for the input!   I'll dig into the Native.log a bit more.  This is one of the weirdest problems I've in encountered in years...   Sort of fun to work with though.


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: Tuesday, August 18, 2015 4:50 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Logout Issue

On 8/18/15, 2:40 PM, "users on behalf of Oak, Joe" <users-bounces at shibboleth.net on behalf of Joe.Oak at StateAuto.com> wrote:

>Scenario 2:
>If the user’s session “times out”, they log back in as noted above.
>Scenario 3:
>If the user requests to be logged out, which issues: 

There's no material difference between those cases from the SP's perspective in terms of what it will send back if it's a protected page. If the session is removed in the second case, either request falls into the "no session exists" bucket and produces the same redirect response.

>If the user now attempts to re-access the site their browser is corrupted and it appears that sessions is “thought” to exist.

Not sure I follow that. If it thought a session existed, it would just use it. That would be bad, of course, based on the description, but it wouldn't generate any redirects.

>Looking in the Shibd log file, I
> see 14 retries of an AuthNRequest.  Each one indicated a redirect the client, but the client never receives of acts on it.

I don't see how there could be more than one then...if it was hung or something like that, there would only be one. Usually a bunch of requests logged is a loop, although 14 is a bit low for that. Is there anything in between them, and what's in native.log? No sign of sessions being created and then immediately a new AuthnRequest issued?

>To add a bit more… If I change the CERT be used on the protected server to an Unsigned Cert, rather than our normal CA-Cert everything works fine.


Well, that obviously implicates the web server and client somehow.

>On the failing session the Server send the client a [FIN,ACK] and the client replies [ack]
>On a different server where all scenarios are working the Servers send a [FIN,ACK], the client sends an [ACK], and then client send a final [FIN,ACK], to which the server responses [ACK].   So, not sure why on the failing server that the client is not terminating the session also.

The code that issues a redirect on Apache is very vanilla. There's not really anything to point to but Apache itself here. I would be less confident of that on IIS because the APIs involved are much less clear, but the Apache redirection approach is pretty well documented/standard.

I would tend not to be focusing on the low level thing here. I'm more interested in what the SP is actually doing vs what you've alluded to it doing.

-- Scott

To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

More information about the users mailing list