Minority Opinions

Not everyone can be mainstream, after all.

SSO Options

leave a comment »

I’ve been involved with implementing single sign-on, from both sides of the fence.  In some ways, it’s really not that hard a problem: One system tells the other who’s logged in, and the second system accepts anyone sent by the first.  Sadly, the details get complicated.

First detail: Has either side already implemented a single sign-on protocol?  If only one side has, then the other is probably best off going with the flow.  If both have, then you get to choose between some sort of shim layer to work between them, or side-by-side protocols for one of the systems.  Both options become nasty to maintain.

Second detail: Do you care where the users are coming from?  If not, then OpenID might be a good option; it lets you avoid storing passwords, while giving you an identifier for each user, and allows users to easily sign up from multiple systems.  Our system, on the other hand, requires a prior agreement with each identity provider; that would require limitations on the allowed OpenID identifiers if we were to start accepting them.  I can see it happening someday, but so far it hasn’t come up.

Third detail: Is it acceptable for one user to jump onto another user’s session?  For news organizations that require payment for certain articles, it may well not be important to know exactly which user is looking at each one, just that someone on that computer has paid.  I bring this up because SAML and CAS have the curious property of initiating the SSO from the relying party’s end.  The user connects to the relying party’s site, and if the previous user hasn’t logged out, then the identity provider isn’t even contacted.  This is completely unacceptable for my project, leading to some unfortunate workarounds involving temporary sessions, protocol-specific landing pages, and superfluous redirections to logout pages.

Fourth detail: Are you going to create accounts on the fly as they log in?  That requires a protocol rich enough to provide information about the user, and potentially about the services to be provided.  It’s highly tempting to use something custom for this case, though some of the existing protocols have the ability to shuttle such information.

Fifth detail: Are you going to implement it yourself, or use a third-party library?  CAS is dead simple for basic usage, but has plenty of pitfalls to work through if you’re going to have multiple partners relying on it.  SAML, on the other hand, is nigh impossible to implement from scratch; even configuring a simple SAML package ranks among the most painful experiences of my life.

Sixth detail: Will the two systems communicate directly to each other, or shuttle all messages through the browser?  The latter is potentially less secure, but eases development and testing.

Seventh detail: Shared secret or public/private key pair?  The latter potentially allows the identity provider to use the same key for multiple relying parties, but can be trickier to set up.

Depending on your specific protocol, there may be even more details to work through.  JSON vs. XML?  The latter makes it more fun to embed certain types of data, but has a far greater impedance mismatch with common programming languages.  I still wish I had known more about JSON back when creating certain parts of our system’s API.

In some ways, I still regret having created yet another SSO protocol.  In others, I still feel it was the right decision.


Written by eswald

31 Jul 2012 at 5:55 pm

Posted in Technology

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s