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.