Shibboleth at NC State » Technical Documentation » Shibboleth Logout

Shibboleth Logout

Logging out from Shibboleth is complicated. There are many levels of sessions that need to be considered, and only so many of those that your SP can control to force a logout. A discussion of this problem is given after our recommendations.

Recommended Logout Process

You should construct a URL that will allow your user to:

  1. logout of their SP session on your host
  2. and then logout of their IdP session at

We're going to construct the logout URL by chaining these two URLs together. The first URL will be told to redirect to the second URL in the chain after they have removed their session.

The SP logout URL is provided by the standard SP handler. When the user visits this URL, their session and associated cookie will be destroyed. The user will then be redirected to the given return URL:

SP Logout URL =

The IdP logout URL is provided by each Identity Provider. By default this handler will end the user's current IdP session. In the future, this handler may also provide Single Logout (SLO) where the user's sessions on other SPs will be closed as well. This is not yet supported by

IdP Logout URL =

Now we construct the chained URL. When the user follows this URL, they will first logout of the SP. Then they will redirect to and logout of the IdP. The user will end on a standard page confirming they have logged out, and suggesting that they close the browser to remove any other session cookies.

To customize this URL for your SP, you should be able to simply replace "" with the correct hostname. It may be necessary to properly encode the chained URLs when they are passed as a parameter to other URLs. This example does no such encoding, and seems to work on most browsers.

Logout Discussion

Logging out from Shibboleth is complicated, because there are at least three levels of sessions you must consider for removal:

  1. Your application session. For example: a Drupal site that checks shibboleth at login to create a session. Once the session is started, the login is not checked again. It is assumed that the user of that session is always the same.
  2. Your Service Provider (SP) session. The SP on your server creates a session in memory, and tracks this session with a browser cookie.
  3. The Identity Provider (IdP) session. When the user logs in to the IdP, they get a session cookie that lets the IdP remember that it has seen the user before. If the same user goes to login to another shibboleth SP, the IdP can reuse the login and pass the appropriate message to the new SP without another login.

In addition, the user may have used their IdP session to authenticate to other SPs in addition. Those SPs will have their own SP sessions and could have additional application sessions as well.

The best that you can do for a logout is:

Legacy Logout URLs for

We still provide a few custom logout handlers that we supported under IdP version 2. These will allow you to send the user to logout of the IdP and then return to a page on your site. These mostly work by loading the standard logout handler in a hidden IFRAME, and then handling the redirection afterward. They may or may not continue to work if/when we enable SLO.

Local Logout

A local logout is performed when you remove the application and SP session information, but do not log the user out from the IdP as well. (Do steps 1 and 2, skip step 3.) You can use the local logout link provided by the shibboleth SP software to do step 2. Just forward the user to your Shibboleth.sso/Logout page. The session data will be removed by the SP and the session cookie will be deleted. The user will be left at a basic local logout page that advises them to close their browser if they want to log out of Shibboleth completely.

The local logout URL will depend on how you have your SP configured, but it will usually look like this:

Keep in mind that with the IdP session still intact, all the user has to do to re-authenticate to your protected site is to visit the URL again. They will be redirected to login at the IdP, which will remember the session. Then they will quickly return to your SP with a new copy of their assertion without requiring another login.

IFrame Logout

This technique is used by the MyPack portal to execute multiple logout page requests from a single page. The MyPack logout URL takes care of the SP session logout. It also calls the IdP logout but does so without using a redirect. Instead, the IdP logout is called in an IFRAME on the page, and that IFRAME is hidden from view by the CSS style.

<iframe src="" 
        style="display:none" title="IDP Logout">
    <!-- Alternate content for non-supporting browsers -->
<iframe src=""
        style="display:none" title="SP Logout">
    <!-- Alternate content for non-supporting browsers -->

This kind of code may be useful to include both the IdP call and the local SP logout call on one page, as shown in the example above. It has the benefit of not bouncing the user from site to site on a logout. It may also create SSL warnings, especially if you try to put these calls on a non-SSL logout page.

View the source of the MyPack logout page for reference.

More Information

See SLO Issues and Logout Configuration on the Shibboleth Wiki.