lolloj - Fotolia
Single sign-on best practices: How can enterprises get SSO right?
Proper planning is at the top of the list for single sign-on best practices, but it's important to get enterprise SSO implementations off to a good start. Here's how to do it.
I've been tasked with implementing single sign-on within our bank. What are some best practices for implementing SSO in an enterprise?
As organizations move their business processes to the cloud to save money and operate more efficiently, they need to deploy a variety of applications from different providers, each of which requires its own set of login credentials.
Implementing single sign-on (SSO) helps to reduce the number of different login credentials employees need to do their jobs, which can become a problem when employees can't remember their passwords and burden their already overworked help desks with password reset requests. In addition, employees who use weak passwords, or even recycle strong ones, can threaten the security of their companies.
These issues can be mitigated by implementing SSO and enabling systems administrators to control the authentication and access management process across different domains. SSO is a session and user authentication service that permits a user to use one set of login credentials -- e.g., username and password -- to access multiple applications.
[Editor's note: This article has been updated with new information on single sign-on best practices and implementation advice]
Planning for a single sign-on implementation
Planning and preparation are at the top of any list of single sign-on best practices. Options for implementing SSO will vary depending on the size of the company and the scope of the SSO implementation. Companies subject to legislative compliance, especially banks, should also consider regulations such as the Sarbanes-Oxley Act and the Federal Financial Institutions Examination Council.
Since an SSO implementation will likely need to support diverse systems and platforms, the first step is to determine which systems to enroll. The choice should be based on the systems employees use most, like email or the corporate intranet if that requires a logon. Second, decide which product best fits the organization's IT architecture and infrastructure.
It's also important to ensure that SSO systems mesh with the organization's existing IT infrastructure. SSO can be implemented in the cloud or on premises; in either case, a gateway authenticates to the member applications. In other words, the user authenticates to the SSO gateway, which then authenticates on behalf of the user, employing the stored credentials for each member application. The SSO system is the master store for the applications' logon credentials.
Since SSO provides a centralized point of access, it can be used to more closely monitor user access; regulations like Sarbanes-Oxley require careful observation. In addition, because SSO installations are complex, they call for extensive documentation on authentication. That's something else that auditors and regulators may want to look at.
Single sign-on best practices
While one of the first challenges when implementing SSO is planning which systems to include in the installation and how to simultaneously sync them up with the SSO technology, SSO is rarely a simple deployment that can be accomplished quickly.
In addition to doing thorough planning and preparation, there are other important single sign-on best practices.
Identify the applications. How companies decide to implement SSO will depend on the applications they plan to access from the SSO. That means the first thing to do is determine which applications need to have SSO; identify if they're web, native or mobile applications; and decide whether a federated solution is required. Then, pick the provider, or the framework, and the protocol. In addition, distinguish between authentication servers -- identity providers -- and authorization servers -- resource servers.
Choose a framework. It is important to determine the best framework for your SSO implementation. The Security Assertion Markup Language (SAML) is a set of open standards and protocols for sharing security information about identity, authentication and authorization across different systems, and it is designed specifically for web applications. The OAuth 2.0 framework, with its associated protocols, is designed for authentication in native and mobile applications that do not run over web protocols.
Verify that the identity directory is accurate. All SSO solutions require authoritative directories that contain accurate information. Since organizations will be consolidating users' identities across the enterprise, they have to match up their users' identities, including employee numbers, email addresses and other relevant data. Companies must ensure that the correct data is populated for each user in the application or users won't be able to sign in after the switch to SSO. This is also a good opportunity for firms to purge the accounts of inactive users.
Secure all the components of the SSO system. Since SSO can be a single point of authentication failure, all the components of the SSO system need to be secured within the enterprise. If a malicious user gets ahold of the SSO logon credentials, all the applications registered with the system will be at risk.
Consider user privileges. Before deploying single sign-on, enterprises need to think about privileges and who is allowed to do what. Companies must decide which protocols to invoke and determine if those protocols fit with the framework they've selected.
Protect privacy. Firms must also consider whether an application needs identity information. Applications shouldn't just grab identity information because it's there. Applications that need to know identify information shouldn't share that information with other apps that don't need it.
Disallow username/password login. Organizations should ensure that their SSO systems can disable employees' ability to sign in using passwords.
Disallow password resets. This prevents users from changing or resetting their passwords via email.
Disallow email address changes. Companies should only allow employees to use their work email addresses because these are the addresses that the firms control. Organizations should never let users change their settings to use their personal email addresses.
Enforce session timeouts. Don't allow users to stay signed in indefinitely. Rather, expire idle user sessions. Have a setting per account or use the session timeout value from the SAML response. When an employee clicks on the link in the application after the session has expired, the app should send a SAML request to the identity provider to determine if the user is still authorized to sign in.
Force sign in. If an app receives a sign in request, but the user's browser has an active session already, that session should be replaced with a new session for the new user. This decreases the risk that one user will inadvertently see another user's data. This also helps employees who use SSO portals to sign in to different accounts in the same application.
