...
There are two modes of operation, SAML and Local. In all cases, the IdP does not initiate requests to SPs and will never inform them of a logout event. It only responds to logout requests, and never sends them.
SAML Logout
In the SAML case, the profile handler lives at the usual SAML binding endpoints at paths like /idp/profile/SAML2/SLO/Redirect (analagous to the SSO endpoints). It will respond to signed LogoutRequest messages from SPs that it is configured to support (this is controlled in the usual way, see IdPSAML2LogoutRequestProfileConfig). When it receives a request, it follows the SAML profile involved, which means that it tries to locate an active session using the <NameID> element in the request. This must correspond to an assertion issued to the SP with that subject identifier associated with an active IdP session. If the client presents a session cookie bound to an active IdP session, then this session MUST match the one identified in the LogoutRequest. Assuming a session can be found, it is terminated.
...
You have free reign within your UI template to add additional processing logic if you choose. For example, you could clear additional cookies that are specific to your deployment and outside the knowledge of the IdP. You could add processing that checks for additional parameters to control what to do after the logout completes. In theory you can use this to integrate into a completely different logout flow. We don't care. Your , it's your code, you do what you want with it. Just understand that exposing that sort of behavior to other systems (such as telling them to send you additional parameters) is on you to support and will not be something the IdP knows about or enforces. Like most of the logout puzzle, this is mostly geared toward enterprise systems that you control.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<prop key="file.resource.loader.class"> org.apache.velocity.runtime.resource.loader.FileResourceLoader </prop> <prop key="file.resource.loader.path">/opt/shibboleth-idp/conf</prop> <prop key="file.resource.loader.cache">false</prop> |
You can adjust these properties as you see fit of course.
If you're paranoid and want to avoid changing the built-in instance, you could define your own, either inside the same file, or by adding a second Spring configuration flefile.
Once this is done, you will need to customize the <ProfileHandler> elements for the SAML2SLO profile handler by adding a pair of XML attributes, as described in the IdPSAML2LogoutRequestProfileConfig topic.
...
A couple of points that are worth highlighting though:
Due to a design limitation in this version, the IdP cannot access more than one session at a time for a given subject identifier. This works ok okay with transient or directed/persistent identifiers, but limits the IdP's ability to terminate all of the sessions associated with an identifier even if that might be useful. Secondly, because of this limitation, the SessionIndex attribute in SAML is ignored.
Also, it's worth noting that this whole mechanism really assumes you're using the IdP's session mechanism, the PreviousSession login handler for SSO, and are clustering state if you have more than one server. If you're going the stateless route (as defined here for example), you probably can't support SAML logout requests unless the "Asynchronous" extension is used. It won't break, but you'll probably end up with a lot of SAML errors returned to the SP because a session won't be found. With the extension, at least you can force it to clear the user's front-channel session (which is probably in a cookie you control) and do other useful things by customizing the script/template. You may have something very much like this already deployed already, so you can either keep it, or switch to something based on this feature if it makes you happier.
...
We have no current plans to deliver a more comprehensive version of this profile handler that does "real" logout by contacting SPs, at least in the timeframe any time frame that includes the V3.0 release. We can't say anything for sure beyond that time frame.
...