In addition, it provides generic hints regarding Single Logout in further scenarios.
This guide documents how to configure a Shibboleth SP to support SAML Single Logout in combination with the SWITCH edu-ID IdP.
Checkout these SLO presentation slides
to get an idea about the user experience and the various cases you will need to test.
That slide set also documents why it is not easily possible to achieve a good SLO user experience with a vanilla Shibboleth IdP.
Deploy single logout on your SP only if it meets the following prerequisites:
Your SP serves only a single (virtual) hostname per entityID (this is the default configuration):
A single entity can have only one well-defined <SingleLogoutService> endpoint per binding.
Cookies are typically host-based and logout cannot be easily implemented across virtual hosts. Unlike during SSO,
a <samlp:LogoutRequest> message cannot specify a particular response endpoint. Therefore, a scenario with multiple virtual hostnames per entityID is not compatible with SAML SLO.
No logout link within your web application may be located within an HTML frame.
Does your web application manage its own application session?
Yes, it manages its own application session:
⇒ It must fulfil these additional prerequisites:
Your web application needs to be able to terminate its application session once triggered by an external event.
The application session timeout ≤ SP session timeout
The application does not trigger single logout as a result of an idle activity timeout.
No, it is fully protected by the Shibboleth SP, it has no application internal session management but relies on the SAML session as managed by the Shibboleth SP, including logout:
⇒ No additional prerequisites to fulfil.
If your SP shall support the SWITCH edu-ID private identity, check out your SP's
entry in the AAI Resource Registry with the Resource Inspector
to display the configuration details ane make sure it's enabled:
That way, you can login to your SP with your SWITCH edu-ID account and properly test Single Logout, unless your SP's access control rules prevent your access ☺.
Since v2.6, the Shibboleth SP fulfils the following requirements by default. If you use some other SP implementation, you need to verify yourself that it fulfils them all:
The SP must terminate the local user sessions before issuing a <samlp:LogoutRequest>.
The SP must use the HTTP-Redirect binding for SLO.
The SP must sign all SLO <samlp:LogoutRequest> and <samlp:LogoutReponse> messages.
The SP must include the <saml:NameID> element in <samlp:LogoutRequest> messages exactly like it received it from the IdP, including its element content and all XML attributes included therein. It must neither encrypt the <saml:NameID> element.
Note for Shibboleth SPs: Ensure your SP config does not include signing="back"
in the <ApplicationDefaults> element (e.g. from an earlier version).
It would override the default signing="conditional" and prevent the signing of a SLO
See Signing and Encryption in the Shibboelth Wiki.
Adapt your SP for Single Logout
To tailor this guide, enter the hostname of your SP and pick its entry from the auto-completion pop-up list.
It will work for the SPs registered in either the SWITCHaai or the AAI Test Federation.
Adapt your web application to handle external logout
You need to apply this step only if your web application handles its own application session. Once implemented, this will fulfil the above prerequisite 3a1).
This step is highly application specific, so we can't provide you a full recipe. The Shibboleth Wiki provides additional information, see:
Web Application Adaptation for SLO.
Once you applied the changes to your web application, add a <Notify> element into your shibboleth2.xml file.
Add it either within the <ApplicationDefaults> or the <ApplicationOverride> element, depending on where your SP is configured.
For details consult the SP Notify page in the Shibboleth Wiki.
The application's logout script has
first to terminate the user's application session
thereafter, it must redirect the user's browser to the URL it got via the return query string parameter.
That script can easily identify and destroy the application session thanks to the cookies the web browser will send to the script on the front channel, due to the HTTP-Redirect SLO binding. Therefore, configure notification only on the front channel. That is sufficient for the HTTP-Redirect SLO binding.
The <Notify> element could look like this, provided you named the application's logout script logout.php:
Verify in shibboleth2.xml whether in all the <Sessions> elements of your
configuration the attribute redirectLimit is set.
Its default setting redirectLimit="none" does unfortunately not prevent open redirect misuse.
See the the Shibboleth Wiki
for all the options available.
Set it in all the <Sessions> elements to redirectLimit="host" to limit
redirects to your own host. This will prevent 'Open Redirect' misuse with the Logout Handler.
In shibboleth2.xml modify the <Logout> element from:
to include global logout via SAML that it will look like this:
The <Logout> element is either located within the <ApplicationDefaults> or an <ApplicationOverride> element, depending on where your SP is configured.
Next, publish the SP's Single Logout capability to the IdP via the federation metadata.
Go to the AAI Resource Registry and activate in the Service Locations section for your SP
the Single Logout Service for the SAML2 HTTP Redirect binding.
Add there its SAML protocol endpoint:
If your SP shall support the SWITCH edu-ID private identity, check whether
the Intended Audience setting is correctly set to included.
If not, fix it now:
Click on submit for approval to finally activate the changes you applied to
the SP entry in the Resource Registry. You will be able to test it, once the change is approved
and the IdPs have loaded the new metadata.
Tailor the logout messages for your SP
The Shibboleth SP provides in the /etc/shibboleth directory three template HTML files you can tailor to your needs:
The Shibboleth Wiki documents the usage and tailoring of these template pages.
The SP e.g. displays the localLogout.html page when it couldn't find a <md:SingleLogoutService> location in the IdP's metadata and it had to fall back to local logout.
Test Single Logout with your SP
Test Local Logout with your SP
Login to your SP to initiate a session by using its Login Handler and choose as Home Organisation to authenticate at the SWITCH edu-ID IdP: Login Link:
Verify with the Session Handler that the SP session is established. Session Handler: