Nice post by Tim Paul on some of the problems he ran into with a customer who had an SSO deployment collapsing because of identity collisions. I love how the problem was solved through the use of a virtual directory.
Great insights, Tim. Thanks!
There was an SSO webinar today by Quest Software. I would like to thank them for actually putting some content into it and actually explaining what their solutions offer. I have become a bit weary of webinars so laden with marketing message, you really have no idea what the technology is offering you or if it will fit your infrastructure or not.
The recording is available here. My big take-away's had a familiar ring to them, as I have repeated some of these points too many times to count at this point. Quest has an offering of multiple applications for an SSO package. Also, check out Mr Shaw's white paper on the subject.
First SSO means different things to different people; enterprise SSO, Federated SSO, Web SSO, Single Password, Reduced SSO, etc. But I believe that some things are the same regardless of the "type" of SSO you want to deploy.
Shaw had a nice list of the "perfect world" for SSO:
- Standards based
- A single password or login
- A single directory
- Strong Authentication support / multi-factor authentication
- Support for multiple platforms
- Support for multiple applications
- Support for "thick, thin, and web applications"
This week I have been faced with some of the problems in solving SSO integration problems and how to deliver identity information to enable SSO. A client had previously deployed a SSO solution for 35+ applications, using only two sources that were disjointed. Now they were faced with integrating another data source that contained intersection of identities. Some users in the new source exist in one of the other two sources - now the entire SSO solution collapses because it was based on the idea that they would never face an overlap of identities within the repositories. Again, the answer was to deploy a virtual directory server as the abstraction layer to simplify the management of identities in these, now jointed data sources.
The lesson is, yes you can deploy an application without building a unified infrastructure, but you take a big risk. When new data sources need to be incorporated (including acquired applications with their respective user-base), you can expect problems.
PLAN AHEAD.. if you don't need to solve this integration problem now, YOU WILL at some point if you expect any level of scalability. YES, it is possible to have one source for all your users, without replication. By using the features of a virtual directory server to create a true union of identities (identities are correlated appropriately and duplicates are eliminated) and extend those entries with additional attributes from the needed data sources, you provide an identity infrastructure to provide authentication and authorization services to your SSO application.
identity management, Active Directory, ESSO, single sign-on, Quest Software