Jeremy Smith's blog

Entry Is Labelled

The Benefits of Single Sign On

Matt Heimbach adds in his Top 10 Case IT Services, and in it, he asks about the benefits of Single Sign On:

I'm going to need Jeremy to help me out on this. I definitely understand the need for one username/password to simplify things... But what's so great about having all web apps redirect to the single sign-on webpage and then divert back? I know it's more complicated than that, but I don't really see the problem with logging in and out of the systems you want to use individually.

The first portion is, quite simply, to make things easier for the user. The theory is, you sign in to one of the resources, and then, when accessing any of the other resources, you aren't bothered with having to supply your credentials again. So, you log on to webmail in the morning; check your email; go over to your blog; create a couple of posts; zip on over to the calendar to check your morning meetings; and quickly pop in to HCM to log some vacation time you took last week. Throughout all of that, you were only asked for your username and password once – when you first accessed your webmail. The rest of the time, the other services know who you are and don't bother with challenging you again.

That's the easy win. Sure, as Matt said, it's not that big of a deal to log in and out of each app separately; but I, for one, am annoyed by it. Obviously, the merit of an SSO solution is only as good as the number of systems that work with it. Some of the apps were easier to port over to it than others. The remaining will take some time.

But, there are a handful of other wins.

If a person types in their password incorrectly, the SSO system can be configured to tell them it was a bad password and present them with links to go reset their password or change it. Similarly for the case of a person's account whose password has expired and they need to renew it. On a system using it's own authentication form (even if it is against our Kerberos or LDAP services), it must be configured separately to give out such helpful links and information. Obviously, with n apps all doing their own authentication, all of them need to be configured to do this themselves – duplication of work. Or, even worse, having the external apps not configured at all and they just say, "your password sucks; go away!" with no helpful information.

Helpful links are not the only scalability and "feature-ability" bottlenecks solved by using an SSO. Have you seen those commercials with the IBM laptops that you just swipe your thumb over a little reader thingy to log in? Biometrics. When we enhance our SSO to accept biometric credentials, anything using the SSO system suddenly will, also, work with biometrics. That is, an SSO system decouples an external service from the authentication method used. We can configure the SSO to use username/password, biometrics, personal digital certificates, voice recognition, etc.; and as long as your app is leveraging our SSO, your app is configured to be able to use all of these different methods of authentication without you lifting a finger.

Federated Identity is a term that is becoming watered down. But, I am not going to get into what it is, what it isn't, and what it means to you. And, while deploying a Federated Identity solution does not explicitly depend on having an Enterprise SSO system; having one does make things easier in that arena. This will become more apparent as we take our Shibboleth service out of closed doors Beta and into production use with OhioLINK as the first offering.

Easier to manage user experience, consolidation of web login services, decoupling of authentication architectures of independent applications, and future-proofing applications to the future of "identity" are the reasons an SSO system is useful, important, and why others would want to leverage it with their own systems.

Comments

  1. gravatar

    Geez, that ended up being a lot drier than what I had intended. Just not feeling witty enough this evening to make it a more enjoyable read. Next time, I'll make sure to throw in some kind of analogy involving sea otters and beer.

  2. gravatar

    That's a really good overview actually :)

    It's really interesting that we seem to be going through much the same situations at the moment with SSO/Shibboleth/Blogs/etc...keep up the good work!

  3. gravatar

    Very interesting...as I expected, you brought up some points that I hadn't thought of. Good post. Is it going to be possible for non ITS systems (like, for instance, the ones I develop for my department) to tie into the SSO system in the future? I'd imagine so, but I haven't really looked to hard into it yet.

  4. gravatar
    Is it going to be possible for non ITS systems (like, for instance, the ones I develop for my department) to tie into the SSO system in the future?

    Oh yes. As of right now, we've had many inquiries into doing so; but no one has actually deployed one. Hopefully, that will change. Documentation for doing so is located at https://its-services.case.edu/middleware/docs

  5. gravatar

    By far the biggest advantage in my mind is the ability to shunt all the transactions involving possibly dangerous data (in this case live username/password pairs) onto a single point of failure. It's Warren Buffett's "put all your eggs in one basket, then watch that basket" model; I'm much more comfortable with the notion of one authentication checkpoint that ITS is watching like a hawk than three dozen web applications collecting the data, then turning around and spitting it towards, e.g., the LDAP server. I'm happier about not having the data, and users should be as well.

    When I was putting together an e-commerce service for a government client at a previous job, we had real difficulty convincing the legal people to sign off on any scheme that involved us holding onto the credit card information; we wanted to blind ourselves from that and let the bank deal with it, because we trusted the bank's IT people to get the job done and because we wanted to offload the legal risk on them. Same principle.

    (Jeremy, as soon as I have a non-self-signed SSL certificate to play with, I'll be in touch about hooking into PubCookie.)