What will happen if?
ndk at signet.id
Thu Nov 1 12:13:06 EDT 2018
I'm not sure what you mean by SAML IDP Cookie. If you mean the cookie associated with the primary login session, it's scoped to the IdP's domain and only used in interactions with the IdP. Presuming various things about your session storage, this cookie would allow the user to authenticate to your IdP.
The SP is never handed the SAML IDP Cookie. It receives an assertion from the IdP indicating the nature of the authentication, attribute information, and so forth, and those typically have a 5 minute lifetime. As such, it's the SP's session that is constructed from the assertion that matters. Once that expires, the user becomes anonymous to your application again, and your application would perform its natural authentication initiation, which in your case would be a redirection to the discovery service. They will not receive an error from the SP because the default behavior is if the user presents an SP session cookie that was associated with a session that has already expired; it's not usable, so the SP treats the access as if it is by a new user.
If you are further worried about IdP's that have very long login sessions and your application wants fresh logins, I would recommend setting the forceAuthn boolean to true in your AuthnRequests, which will require the IdP to reauthenticate the user before issuing an assertion to your SP.
From: Dan McLaughlin
Sent: Thursday, November 1 2018, 4:00 pm
To: Shib Users
Subject: What will happen if?
If you have the SAML IDP Cookie set to expire every 365 days, and you
remove the IDP from the list of trusted metadata, what will the SP do
the next time it get's handed an IDP cookie that it no longer trusts?
What I would like it to do is hand them off to the Discovery Service
to select a new IDP, but I have a feeling they are going to get an
error from the SP instead.
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users