Single sign-on (SSO) solutions let an end user log in just once and access all the resources and applications they need.?SSO systems make it easy to authenticate the user once and thereafter be automatically authenticated when accessing related systems. Thus, SSO eliminates the hassle of separately signing on to multiple applications and systems. One set of login credentials is all the user needs. This removes the frustration of remembering countless usernames and passwords.
See our picks for top single sign-on solutions
How single sign-on works
Single sign-on involves authenticating a user’s identity and then authorizing access to the service or application the user is requesting. It achieves this by retrieving the user’s profile. These profiles could be stored within the SSO system, in a directory such as Microsoft Active Directory, or in an HR system.
SSO validates the user based on user inputs. These inputs could simply be the correct username and password. Some solutions incorporate additional inputs such as user IP address, location, time of day, device info, last login attempt, whether Apple FaceID was used, and more, adding additional layers of security beyond username and password.
After validating the user, the single sign-on system allows access to the requested resource. For some resources, this entails automatically populating credentials. This is similar to some consumer-oriented password managers that automatically enter your username and password when you visit a vendor website.
Enterprise password manager: SSO for enterprises
Enterprise password managers have taken the concept of single sign-on to another level. These password managers provide a single place for users to authenticate and manage their credentials. From the central authentication point, the password manager offers credential management for each integrated resource as well as delivering an SSO experience to the user.
The main difference between enterprise-grade password management compared to basic SSO is the ability to centrally manage users across the organization with sets of policies that enforce corporate security standards. This is done through a global console used to manage the entire environment. Additional administrative features included in enterprise password managers include the ability to assign and revoke access to certain apps, viewing password health among the user base, triggering additional authentication measures, and connecting to Microsoft Active Directory.
An Enterprise Password Manager also provides an SSO experience to the end user in situations where applications may not support a technology such as federation. Every application still has its own login, but application credentials are stored in a secure vault, where they are retrieved and replayed to the applications as needed. The user experience usually consists of logging in once to unlock the secure vault, then logging in to applications is automated.
These days, the lines between SSO and enterprise password managers have blurred. SSO solutions have been developed that:
- Enable federation, removing the need for passwords all together
- Take in context around the user such as location and device
- Connect to multiple directories such as LDAP, HR systems, internal databases
- Enable API level access for more customized usage
- Offer sophisticated auditing and compliance reporting
SSO vs. multi-factor authentication
SSO is all about users gaining access to all of their resources with a single authentication. Multi-factor authentication (MFA), on the other hand, offers a stronger verification of the user identity, often used for a single application. An additional factor is required beyond what has been supplied for the login. This might be something a person knows (PIN, answers to personal questions), something the person possesses (a physical token or key, smartphone), or something the user is (biometrics such as a fingerprint, retina scan, etc.).
MFA adds an assessment of risk. SSO might be used for most systems and applications, but MFA can be invoked for access to more sensitive information. This is commonly seen in corporate environments when one login can gain the user access to routine systems, email and more. But when you try to use the corporate VPN, or enter systems via a smart phone, a code is transmitted as a further method of authentication.
Tiered access, then, has become more prevalent as trends such as the cloud, mobility, the remote workforce, and bring your own device (BYOD) have evolved. As most network breaches occur through stolen or hacked passwords, multi-factor authentication and network access controls increasingly complement single sign-on. And MFA is often a requirement for regulated data as a way of satisfying government mandates.
SSO implementation
Single sign-on approaches vary. Typically, it is done either as an application running on an end node, or on an intermediate or federated platform. In each case, single sign-on implementation is used to authenticate the user’s identity only once, which in turn authenticates on his or her behalf to other applications, websites and resources.
SSO, then, operates as a virtual surrogate between client devices and target systems. Single sign-on systems respond to authentication prompts from applications and systems, providing them with valid credentials. It provides a unified and seamless experience for accessing internal and external web-based applications.
Passwords are often the primary means of user identification. However, a more secure way to connect users to their resources is through federation. In a federated model, trust is made between the SSO solution and the resource on the backend. Once the SSO solution validates the user, the resource automatically allows access without additional validation such as a password.
In a federated scenario, a user logs into a service called an Identity Provider (IDP). The IDP then provides some type of token, assertion or ticket to an application (referred to as the relying party because it relies on the IDP for its authentication). The most commonly used technologies for federation are Kerberos, Security Assertion Markup Language (SAML) and OpenID Connect (OIDC), said Ben Goodman, Vice President of Strategy and Innovation at ForgeRock.
SSO authentication approaches
Single sign-on implementation, then, can be achieved via different architectural models. In many cases, they are used together to provide the best experience to the user.
The least common approach is to synchronize credentials across all the resources used. While this approach may be used for a few applications, it typically isn’t practical in diverse environments because of the dissimilarity in credential requirements across identity stores. It is also less secure: if the credentials for one of the systems are compromised, they all are.
Another single sign-on approach is for a user to authenticate once into a central identity provider that in turn authenticates on behalf of the user to each resource being accessed. This enables the introduction of unique credential policies or requirements, as well as adding an extra level of security by obfuscating the actual credential from the user.
There is also the federation or trust model, in which each application, platform or other type of resource trusts the identity provider to allow the user access. This eliminates the need for any type of synchronization. Cloud-based services favor this model. But federated identity goes beyond the cloud to encompass on-premises and hybrid applications.
Browser plug-ins, too, can be used to insert credential information through an HTML form fill. This requires the user to initially go through the authentication process manually, from which the plug-in records the credential information as part of single sign-on.
While it may be easy for startups or cloud platforms to focus on one of the above types of single sign-on implementation such as federation, many enterprises have to use a mix of these technologies. As they are likely to comprise a diverse collection of modern and legacy resources, a combination of single sign on approaches is required deliver a full SSO experience for all users and systems.
SSO trends: mobility, federation, analytics
What trends are apparent in the SSO market? The demands of a more distributed workforce have added to the sophistication of mobile applications. This, in turn, makes SSO a fundamental requirement: The same level of backend complexity used to populate a portal or web page is now required for mobile apps. A successful mobile single sign-on implementation calls for an SSO architecture driven by policies to be applied to the context of a request. In some cases, those policies will bring into play an MFA prompt.
Further trends include federation. It appears to be gradually replacing other forms of SSO. This is being driven by increasing movement toward cloud native applications. As more applications and functions end up in the cloud, identity functions need to be centralized.
Analytics, too, have entered the single sign-on equation. In the last year, more emphasis has been made to build adaptive single sign-on capabilities. This enhances SSO by taking into consideration far more contextual data points around the behavior of the user such as the impossibility of travel arrangements. Say, for example, a user logged on from his office in New York five minutes ago could not log in from Las Vegas.
“Adaptive SSO creates a far more complete picture of a user attempting to gain access and puts security teams in a position to more effectively determine whether a login attempt is being made from a legitimate source,” said Daniel Lu, Senior Product Marketing Manager for SSO at Okta.
SSO buying tips
There are a great many vendors operating in this space. These include Okta, ForgeRock, Micro Focus, OneLogin, CA Technologies, Oracle, Ping Identity and Centrify. Between them they offer a wide range of SSO solutions. Some are better on-premises, others in the cloud. Here are a few things to consider during the product selection process:
- Application and resources can be diverse. Therefore, categorize authentication types (end node, centralized, federation, form fill) in order to understand which ones are offered by the vendor candidates. Some organizations may need a wider range of single sign-on types than others. And on the other side of the coin, why pay for single sign-on capabilities that aren’t required?
- Complex environments may need to engage in user prioritization to decide which authentication requirements are vital, desirable or unnecessary for each category of user. This will help the organization to understand the level of SSO functionality required and the sophistication level of the platform that should be selected.
- Try to keep single sign-on simple. Enacting MFA policies across the enterprise may be overkill. It can also inhibit efficiency and even cause users to avoid certain applications. SSO should favor frictionless access.
