Sometimes, there seems to be confusion over what "Single Sign On" (or "Initial Sign On") is and is not. Some people think that the fact that you use the same credentials to access Resource A and Resource B; well, that's Single Sign On. Nope. That's just signing on to things with the same credentials — there's no fancy term for that because it isn't at all impressive.
Some people say "Single Sign On" in the same breath as the portal. The portal is "kinda" single sign on in that it "fakes" single sign on by proxying credentials and, programmatically, signing on to services like mail and calendar. But, it's not really single sign on in the sense that it provides an infrastructure which external applications can hook into. (Well, at least, in no way that I have ever figured out to use.)
So, what Case needs is a real Single Sign On solution. One that provides an actual Middleware framework that any arbitrary application can hook into be it the portal, or webmail, or calendar, or blog, or any little random CGI script. Heck, in a perfect world, even non-ITS offered systems (like student run systems or systems set up by the IT departments in Weatherhead or the library) could leverage the infrastructure.
So, what does Single Sign On enable?
The much ballyhooed use-case is a person who gets to work in the morning. They fire up their web browser to access a technology resource. The resource they are requesting asks them to sign on. They do so. And, from that point forward, any other resource they request no longer challenges them for a password because all of the disparate resources can negotiate with the SSO system to determine if the user has already logged on.
Not only are SSO systems nice and conveniant, but one is necessary as we move forward with the implementation of Federated Identity.