We're probably not too different than many
places where we have many applications each using its own
authentication mechanism from disparate data stores. The primary goal
here is to unite all these applications to use the same authentication
mechanism using a single data store, hence a single username and
password. Because we deal with clinical data, HIPAA comes into play.
So certain applications need specific restrictions, for instance
having a session timeout in 15 minutes. Other applications -
administrative, those for developers, IT staff - can be logged in all
day long. Therefore our secondary goal is to place these policies
across all the apps. We have our own authorization and audit system
and won't be using those from OpenSSO.

We also have the case where we need to federate to other identity
providers, such as caBIG, so our users can seamlessly use the grid
applications. But we also share data with labs and other facilities
that develop their own applications and need to federate identities
(and authorizations) to us either through user interaction and/or web
services. And in one special case, we have an authentication module
that authenticates users via webservice to CTSU where they don't
yet have federated identities.

This is a great mini-case study of an OpenSSO deployment - internal SSO, federation, web services and a bit of customization on the side. It's great, too, to be able to support such vital research through OpenSSO - CALGB didn't have to ask or tell us about their OpenSSO deployment - they just got on and got it done, and were good enough to share their success story with us.