Logout Issue

[Cantor, Scott]

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: 
>https://xxxx.com/Shibboleth.sso/Logout

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.

Uhh...

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