IDP logout customizations

Manuel Haim haim at
Mon Apr 8 09:43:51 EDT 2019

Hi there,

we also have some customizations here in Marburg, Germany (still IdP 3.3.1).

First, we don't allow redirects after logout, but just stay at the IdP's
logout page (logout-complete.vm). The logout page shows all service
providers' names and logout states (success, failure, pending, not
available). It took some time to convince our local service providers
that we cannot redirect to them after logout, but they are just happy
now as we provide a hyperlink (service URL with <a target="_blank">
which opens in a new tab) for each logged-out service, so the user can
easily get back.

Here is what I have done:

Activate SP session tracking and lookup in
# Track information about SPs logged into
idp.session.trackSPSessions = true
# Support lookup by SP for SAML logout
idp.session.secondaryServiceIndex = true
# Whether to lookup metadata, etc. for every SP involved in a logout
# for use by user interface logic; adds overhead so off by default.
idp.logout.elaboration = true

I added a patch to add additional states ("pending" and "na"):

On logout, the first endpoint within the metadata is contacted. If this
is of type "Artifact", the SP will ask the IdP for the SAML message.
Thus the IdP must have ArtifactResolution enabled (which, however, would
also be required for SAML1 logins, but could be bypassed in
relying-party.xml using <Shibboleth.SSO
p:includeAttributeStatement="true" ...>).

Activate ArtifactResolution in
# Enable ArtifactResolution
idp.artifact.enabled = true
# Our IdP is clustered, so we also use the StorageService
idp.artifact.StorageService = shibboleth.JPAStorageService

I also needed to add a patch to expose the ProfileRequestContext:

Then, I added a workaround to show the Logout-initiating SP:

Kind regards,

Am 04.04.19 um 23:15 schrieb Liam Hoekenga:
> I'd like to talk to list members from institutions that have customized
> the logout behavior of IDP v3.
> We're migrating from a legacy sso solution, and had previously
> "customized" the provided logout functionality to tie it into the SLO
> for our legacy solution (more "rip and replace" than customize).
> After talking to our stakeholders, the desired behavior seems to be..
> - logout of service provider (kill application and SP sessions)
> - kill IDP session
> - if service provided a redirect URL, send the user to that location
> - user must log in again before they're able to access that service provider
> I've been in touch with Minnesota and they have some stuff that looks
> promising, but also requires the alteration of the system logout flows. 
> I'd like to see what other places have done to try and figure out what
> we want to do.
> thanks!
> Liam

More information about the users mailing list