Reopened: Re: SessionNotFound

[Martin Haase]

Hi list,

I need to revoke my findings. I have tested this again: same user, same
SP, using a non-tranisent NameID (uid).

The flow: Login in Browser A, Login in Browser B, _wait an hour_, Logout
in Browser B, then Logout in Browser A.

This is what happens when using SAML SLO (<SP>/Shibboleth.sso/Logout):
upon the second logout, the IdP returns the SessionNotFound Error, no
propagation, the Browser A user is still logged in at the SP.

This is what happens when using the proprietary SLO
(<IdP>/idp/profile/Logout): upon the second logout, the IdP says the
logout is completed, however no propagation and the Browser A user is
still logged in at the SP.

I can provide debug logs to highlight the difference between correct and
incorrect SAML SSO on the one hand, and correct and incorrect
proprietary Logout.

What ways would you recommend to handle this? In our set-up, the flow
sketched will happen frequently. However I could tweak almost every
variable in the IdP and SP since I basically control them. The shared
accounts are marked in our LDAP, so the last resort would be to write an
IdP intercepter that tells these users to be careful about SLO. Other
ideas?

Regards

Martin

P.S. what puzzles me is that without waiting the hour, everything seemed
to work. Is there some setting besides the ones in idp.properties that
dictates this hour lag? Something in conf/authn?


On 21.04.2017 10:09, Martin Haase wrote:
>
> ...and yet another finding: issuing an invariable (i.e. non-transient)
> NameID at the IdP (e.g. persistent, email, or unspecified) does *not*
> cause the SessionNotFound error, so this is another possible solution.
>
> Cheers
>
> Martin
>
>
> On 21.04.2017 09:23, Martin Haase wrote:
>> Hi again Scott,
>>
>> thinking about it a second time, mitigating the error message about this
>> would be helpful, because sharing accounts is what people do. Because
>> this is actually common in our project, I think we will switch to the
>> "Simple Logout", which seems work regardless.
>>
>> Thanks again,
>>
>> Martin
>>
>>
>> On 20.04.2017 19:19, Cantor, Scott wrote:
>>> But just glancing at the code, I could imagine some less ambitious changes that might address your specific issue because that's more about the reverse mapping step.
>>
>>
>
> -- 
> Dr. Martin Haase, Solutions Engineer
>
> DAASI International GmbH        
> Europaplatz 3                   
> D-72072 Tübingen                
> Germany                    
>
> phone: +49 7071 407109-0
> fax:   +49 7071 407109-9  
> email: martin.haase at daasi.de
> web:   www.daasi.de
>
> Sitz der Gesellschaft: Tübingen
> Registergericht: Amtsgericht Stuttgart, HRB 382175
> Geschäftsleitung: Peter Gietz
>
>

-- 
Dr. Martin Haase, Solutions Engineer

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-0
fax:   +49 7071 407109-9  
email: martin.haase at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170602/42ef4da9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2267 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20170602/42ef4da9/attachment-0001.p7s>