Single Sign-On Buying Guide
Deploying a single sign-on system can improve productivity and lead to better password hygiene, but it also carries some risks.
Increasingly stringent password and access control requirements have had some unintended consequences. Most enterprise systems demand a password – so the average user may end up with dozens of different passwords to remember. The problem is worsened by the fact that many systems demand increasingly complex passwords with at least eight characters including capitals and lower case letters as well as numerals and symbols.
Forgot a password, these days, and the system may not let you reuse an old one. And that is why you see sticky notes pinned to computers or sheets of paper in desk drawers listing all the user passwords that the poor user can’t hope to remember anymore. The only other option is using the same one or two passwords on every system.
“Single sign-on (SSO) grew out of the proliferation of passwords and the poor credential hygiene that users can have as a result,” said Darren Platt, senior director of engineering, RSA.
The result of this password labyrinth, he said, is reduced productivity for employees who have to log into each of their application tools individually, lower engagement for online customers who don’t want to fill out "yet another" form and "islands of identity" that have been created in the different application platforms.
Single Sign On Benefits
“Companies want to leverage a different form of authentication to initiate a session – especially because SSO enables one authentication event to provide access to many different resources,” said Platt.
He lists benefits such as
- Less friction in the user experience. Users can navigate from one service to another without having to authenticate to each one uniquely.
- Less memory dependence. The user doesn’t have to remember/manage as many passwords, and so may have better password hygiene.
- Users are not as likely to have passwords written down on a sticky note in an accessible place.
- Users are less likely to use the same password across a variety of services and security domains.
- Because the users only have to remember one password, it provides the opportunity for them to create a stronger password because they don’t have to remember as many.
- Authentication policy definition. Enterprises can define policies about the types/methods of authentication that are required for a specific access request, taking into account the context of the request itself – including information about the user (including their role), the location of the client making the request, the security posture of the device and the behavioral patterns of the user. In most cases, this includes the ability to require the user to step up to a stronger form of authentication when accessing more sensitive resources.
- Authorization policy enforcement. The SSO system enforces policies about whether users should be able to access a given application based on context information like user attributes (including their roles), the location of the client making the request, the security posture of the device and the behavioral patterns of the user.
- Audit trail. The SSO system creates an audit trail of user access information. Different approaches to SSO provide different levels of granularity in the audit trail. Traditional federated SSO approaches are able to provide visibility into when users logged on to a given application and the type of authentication they provided. More traditional Web access management (WAM) approaches – whether proxy or agent-based – enable greater visibility into user interactions, providing information about all of their interactions with a protected application.
“SSO makes your life easier by trusting a service to do the authentication on your behalf,” said Bernard Van De Walle, technical director at security startup Aporeto. “The fact that the user doesn't need to generate a new password is a good thing as it has been proven multiple times that in most of the cases they will reuse a simple password when signing-up for a new service.”
The single sign-on (SSO) marketplace is one of the more dynamic areas of the security sector. Analyst firm MarketsandMarkets said this market is expected to grow from $845.6 million in 2016 to $1,599.8 million in 2021. It cites major growth drivers, such as the convenience offered by SSO to manage multiple applications and domains, productivity boosts, along with helping the IT department and administrators to manage multiple accounts for numerous users.
“SSO is being adopted by small and large enterprise users across various region of the world,” said Shikha Kumar, an analyst at MarketsandMarkets. “The big trends are an increase in demand for cloud-based SSO and file-sharing applications among SMEs, as well as increasing adoption of SSO solutions across the education, communications media and services, healthcare and life sciences, and travel and hospitality segments.”
Single sign-on, then, addresses a couple of different problems. The most visible one to the user is that it results in having to use only one username and password to log in to multiple systems. However, this is accomplished not by sharing passwords among multiple systems. Instead, the user will log into the SSO system, and the other systems are relying on the SSO for authentication, and in some cases for access control.
For administrators, this simplifies user management and privilege management (access control),” said Dr. Johannes Ullrich, dean of research, SANS Technology Institute. “Typically, SSO systems are implemented using identity management which includes authentication as well as access control.”
He noted the rise of federated identity as an important force in this space. With federated identity, SSO systems can grow beyond a particular organization’s perimeter by exporting trust to other organizations like suppliers/vendors and customers. Ulrich’s advice is for organizations to implement it as part of an identity management suite. He said there are a number of commercial solutions available to implement identity management.
But implementing SSO is no walk in the park. Ullrich said integration of legacy systems can be a real issue. This can result in incomplete SSO implementations that don’t provide the security and efficiency payoff users expect from single sign-on. This often leads to user resistance to SSO, he said.
Kumar also brought up the subject of integration. Improper integration of SSO, he said, can expose IT infrastructure to various risks. It can act as a single point of failure. If key access details are hacked, the security of all connected applications is compromised.
“Most SSO implementations are not backed by strong authentication systems such as smart cards, biometrics and token-based authentication systems,” he said. “SSO is also not a safe option for multi-user devices.”
But deployment of SSO is not always straightforward for existing applications. It is often challenging to create another way to establish an application session beyond existing login capabilities. This usually requires code changes.
“The best approach to accommodate this is to use an SSO product that provides the most options for this ‘last mile’ integration – including password vaulting (for applications where code change isn’t feasible), HTTP header injection (using Web access management systems), and federation (accomplished using standards-based or proprietary toolkits),” said Platt.
In addition, he made the point that Single Log Out functionality is not widely implemented by software as a service (SaaS) vendors. The result is that the end users may think they’ve logged out of all of their applications when they have only logged out of one of them. This can be particularly problematic when the access device is shared across several users. This challenge is typically mitigated by educating the users about how logout works, including the messages users see as they log in and out of the system.
Standards should also be paid attention to during implementation, said Platt.
“SSO between enterprises or security domains is best accomplished using a standard like SAML or OpenID Connect,” he said.
However, many enterprises require more options than these for providing SSO to home-grown applications because in many cases it doesn’t make sense for these standards capabilities to be built directly into every application. It might be better to leverage a centralized service to provide these standard interfaces for those applications. Many organizations, therefore, prefer to wrap applications in these capabilities rather than asking their application developers to build these security features for their applications.
Flexibility is yet another area to emphasize. Platt believes SSO systems should be flexible enough in their integration approaches to meet the security and risk management needs of an enterprise. If a company needs centralized visibility into the actions its users are taking within specific applications they are accessing, for example, a proxy or agent-based approach is the only way that they can get this visibility. Where a company only needs to know when a user logged into a given application, though, a federated approach may be more expedient.
“An optimal solution enables the company to decide which approach they will take on an application-by-application basis,” said Platt.