[JIRA] Commented: (SSPCPP-508) Logout as User A, Logon as User B get UserA's session

[Scott Cantor (JIRA)]

    [ https://issues.shibboleth.net/jira/browse/SSPCPP-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14424#comment-14424 ] 

Scott Cantor commented on SSPCPP-508:
-------------------------------------

I need very detailed logs of all of that. There's no way you can recover a session that's gone, so that means it's not actually being removed and it means the original session cookie is also still intact, which is essentially impossible. The cookie issue in particular makes the storage choice irrelevant. Even if the session were there, the second login would issue a new cookie and overwrite the original, making the old session orphaned in the cache.

You're sure there's no page caching that's making it look like the original session is intact? Including calls to the Session handler in the log traces would also be crucial. Both native and shibd logs are needed.

> Logout as User A, Logon as User B get UserA's session
> -----------------------------------------------------
>
>                 Key: SSPCPP-508
>                 URL: https://issues.shibboleth.net/jira/browse/SSPCPP-508
>             Project: Shibboleth SP - C++
>          Issue Type: Bug
>      Security Level: Standard(Standard bug, may impact functionality but does not represent a security vulnerability ) 
>          Components: Session Cache
>    Affects Versions: 2.5.0
>         Environment: Windows 2008R2 on Azure
>            Reporter: pbrears at idp.protectnetwork.org
>            Assignee: Scott Cantor
>              Labels: Session
>
> Using two servers with the odbc connection plugin for the storage service you can:
> Logon as UserA, Logout of SP via Shibboleth.sso/Logout, redirect to Shibboleth IdP Logout to kill cookie, 
> (don't close browser despite warning message on our IdP logout page...)
> Check SP session has gone via Session dumper
> Go back to SP
> get redirected to IdP
> Logon as UserB
> Get redirected back to SP
> Sometimes (50% of time?) at this point instead of creating new session for UserB it gives you UserA's session
> Environment As per SSPCPP-507. (this might be two symptoms of the same bug but because the symptoms are different I've created two bugs)
> We're using "SQL Server Native Client 10.0" driver to access SQL azure for the db
> There are two servers in the non sticky load balancer. It's likely that /SAML/POST and /Secure are landing on different boxes.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira