Considering setting up Single Logout (SLO) with one or more partners? Well, there's probably a few things that you should think about. And then, you should proceed with caution.
Recently, one of our customers asked a question over in our discussion forums about whether or not people are doing SLO. This prompted some discussion internally, the results of which are summed up here.
Ultimately, I'm going to discuss this from the perspective of the Identity Provider (IdP) since it primarily affects them.
How does SLO work?
First, we should probably level-set how SLO works, just so it's clear to everyone.
(If SP-initiated) An SP sends a logout request to the IdP
At the IdP, for each SP to which the user has authenticated:
The IdP sends a logout request to the SP
The SP attempts to clean its session for the user and sends back a logout response indicating if this was successful
The IdP destroys its session for the user
(If SP-initiated) The IdP sends a logout response to the initiating service provider which then cleans its session.
That "for each" in step two is really important, so bear it in mind as we discuss the possible pitfalls.
Enterprise users and SLO
When it comes to your typical enterprise user, using SLO doesn't really make that much sense. Why? Because enterprises are going for not just SSO to their service providers, but seamless SSO. They want to take some enterprise authentication method and get everywhere.
In some instances, the authentication method is the Windows authentication. Obviously, you can't destroy the Windows authentication. Can you imagine a federation SLO logging someone out of their desktop? That could be disastrous, were it possible.
In other instances, it may be a web access management product like Oracle Access Manager, or Tivoli Access Manager. That step three above comes into play here. Hopefully the admin that creates a user flow that logs an accountant out of Oracle Financials behind the WAM product just because that accountant logged out of WebEx via SLO has an up-to-date resume.
At my former employer, we simply decided not to do it: the risk was too great of not understanding every use case, and we didn't want to take the chance of logging a person out of an application that they were actually still using.
Do all my service providers support SLO?
That's a really important question to ask yourself, so let me ask you again - do all of your service providers support SLO? If they are compliant to the specification, they should, but, how many of your providers are using DIY SAML implementations? A single failure from a provider will generate an error to your users, one that is along the lines of "logout failed". You're going to increase helpdesk calls with that one.
You can mitigate this to some degree, by stating in your contract that your provider must support SAML2 SLO Protocol, as defined in SAML-CORE, and if they don't support it at contract time, maybe they will soon. Maybe.
The chink in the SLO armor
SSO and SLO both use a session at the IdP. The session keeps track of all the assertions you've gotten. If something happens to that session while you are using a service generated from that session, so what? What about when you want to use some other service? You have to log in again? Aside from the minor inconvenience of typing in a username/password, what's the big deal?
For SLO however, it's a bit different. That session is really important, and so is the availability of all of the service providers that the session has in it. Things break all the time. Maybe your service provider is doing an announced upgrade; they are amidst an outage window that they've notified you about. Your end user clicks the logout on some other site, and they also have a session going at the provider that is having the outage. The process runs smoothly until it hits that provider that isn't available, for whatever reason, and just like in the previous section, they get an error that something didn't work right, and they aren't logged out. More helpdesk calls. Your helpdesk team is loving you, right about now.
And what if something happens to the session itself? Your users are all happy, getting into their cloud applications without having to enter passwords. It's a glorious day. And then, disaster strikes. Your trusty hardware guy trips over the power cord in the server room and shuts down a whole rack of servers, including your PingFederate server. Leaving the whole failure to architect for disaster recovery out of the discussion, when your user tries to logout and the IdP server isn't available, guess what they get? If you guessed a "Page not available" error in their browser, you win a prize. Essentially, a new error. More helpdesk calls. At this point, your helpdesk might considering putting a contract out on you.
Forewarned is forearmed
Sometimes we struggle to get SSO working nicely. And while SSO is "one-to-many", it's really just a bunch of one-on-one connections, generated from a single IdP token of some sort. SLO sounds really cool, but in practice, there's just a lot that can go wrong - because of the fact that it ties all of the sessions together in one big process. Anything wrong, anywhere, and that process breaks.
So, the question asked in our forums was "Is the prevailing view for PingFederate to either use SLO or to not use SLO?" While I can't answer from your perspective, or any other company's, I can provide you with the knowledge to help you make the decision on your own. Think about how you do SSO today. Think about the pitfalls I've mentioned. And then, make your own decision.
One last comment for the service providers out there... If you're telling your customers that you're SAML2 compliant, and you don't support the single logout protocol... You're not compliant. Standards are important in this age of cloud computing; please follow them!