Shibboleth has a long and tortured history with logout as a concept, and nothing's really changed in that regard, but after many conversations, we have provided a very limited form of logout as part of V2.4.0 that supports the basic use case of terminating a client session with the IdP. This is a very difficult feature to explain to a user, and should only be deployed after careful consideration.
...
In the SAML case, the profile handler lives at the usual SAML binding endpoints at paths like /idp/profile/SAML2/SLORedirect/RedirectSLO (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.
...
To do this, you first need to define a VelocityEngine instance that can locate templates in the filesystem. You can do this without much harm (that I can see) to the built-in instance that is defined in internal.xml, at your own risk. To do this, add ", file" to the end of the value in the resource.loader property, and add some additional properties as follows:
| 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> |
...