When single sign-on fails, is a second SSO implementation worthwhile?

Several years ago, our company attempted an enterprise single sign-on (SSO) implementation for unified access to the corporate network and applications, but it didn't work out. The integration was too difficult due to some proprietary authentication technology we use, and there were unexpected costs. Given that many of our leaders now feel negatively about SSO, do the benefits merit trying again, or should we set lower goals? If so, what should they be?

Single sign-on (SSO) was one of the hottest security industry buzzwords a few years ago, hitting many organizations like a tornado, sucking up resources indiscriminately and leaving systems engineers and project managers disoriented. However, many attempts to deploy SSO failed. Was this because of bad technology or unrealistic expectations?

SSO seems to offer many benefits. It can ensure consistent access control across the enterprise and external providers, potentially reducing support costs related to authentication. However, implementing it is a complex effort. SSO is only successful when an organization has comprehensive documentation of its business and service technical catalogs. Unsurprisingly, many deployment attempts fail because the projects are initiated without a strong understanding of existing application flows and dependencies across the business. In addition, if there is a lack of knowledge regarding the current types of authentication protocols used by these applications, it can require expensive middleware products acting as translators or glue to make everything use a common interface such as SAML.

Many underestimate the level of effort the endeavor entails, dooming the project before it even begins. To be successful, a proposed SSO rollout should include a discovery phase that inventories applications, their dependencies and authentication protocols. The project team should include non-IT stakeholders who can provide constructive feedback on the user experience during the life of the project. Otherwise, the attempted implementation results in senior management apoplectic over missed deadlines and an ever-extending timeline.

Ironically, the security issues that SSO is supposed to address can worsen with its implementation. If the password policy is weak or the protocols are insecure, then all your eggs are in one flimsy basket. Connections to the authentication system should be encrypted and standardized on a limited number of protocols. Using passwords should entail a strong policy with regular expirations, but one-time passwords (OTPs) are preferable.

Finally, it's important to remember that identity access management is the intersection of user and data classification. Without proper classification, attempts to implement SSO or even identity management systems will be problematic and likely collapse. SSO is a worthy goal, but it requires preparation prior to buying and implementing a product in order to be effective.

What's your question?
Got a question about identity and access management technology and strategy in your organization? Submit your question via emailtoday and our experts will answer it for you! (All questions are anonymous.)