A well-executed single sign-on (SSO) strategy reduces password-related support incidents and provides users with improved convenience and more-efficient authentication processes. A sound SSO strategy will give users fewer reasons to write down passwords. However, one password providing access to all in-scope systems can lead to compromised access to those systems.

Mobile devices can pose further challenges for SSO. The following step should be used to appropriately scope the target solution set.

  • Assess the Current Environment and Pain Points: The first step is to scope the problem space by identifying the user population and use cases that require a solution, and to inventory the target systems, their architectures and the anticipated lifetimes.
  • User population: Identify whether a solution set should cover employees, contractors, external business partners or consumers/constituents.
  • Use cases and applications: Identify the logical location of users and the target systems that must be accessed — for example, internal users accessing internally managed applications and software as a service (SaaS) applications, or external consumers and business partners accessing internally managed applications. Identify the applications and use cases that are currently used the most and generating the most calls to the help desk for authentication-related issues.
  • Applications and their architectures: Determine the application architecture for each application deemed to be in scope for an SSO initiative.
  • Evaluate Anticipated Changes to In-Scope Applications: It’s important to determine whether the applications used today will still be in scope over the next few years. If an application will be retired or replaced or have its user base significantly reduced within one to two years, then it can possibly be removed from consideration and, therefore, reduce the problem space. Approaching commercial application vendors to ask whether there are any plans to provide authentication options that can leverage the enterprise standards is also a good idea. A matrix with the inventory results should be drawn up to help identify common architecture and use case patterns.
  • Leverage Currently Owned Services or Solutions to Reduce the In-Scope Applications: Identifying existing tools that could help reduce the problem is essential. Their use may be isolated to one business unit or application set when they could be more broadly deployed. Sometimes reduced sign-on (RSO), enabled by an established password synchronization tool or authentication to a common LDAP-accessible directory, will provide good-enough reduction in the problem space. When multiple directories are used for authentication, directory synchronization or virtual directories may be brought to bear to join disparate identity sources and to expose one standardized view of identity to multiple applications or authentication services, such as a WAM tool. This can provide RSO or SSO, depending on the configuration.
  • Select Solutions to Resolve the Remaining Requirements: Application designs are moving toward Web architectures. As soon as currently owned directories, Kerberos and password synchronization tools have been leveraged, it is likely that tool or service selection will be based on the need to support SSO to Web-architected applications. Furthermore, SaaS adoption has been driving the need for federated Web SSO. Therefore, the solutions that support these needs should be presented first, with less prevalently needed solutions following.
About these ads