Make SSO great again!?
Hi everyone, I’m excited to be back with our 3rd column of the ‘To Do or Not To Do’ series. In this piece, we look at ‘Single Sign-on’ and dissect its good, bad, and ugly.
The bad? The ugly? Wait, are we suggesting that SSO could be better and there is more to consider while implementing it? Yessir - the world isn’t perfect (nowhere close!), and there are these small minor things called tradeoffs that need to be considered while making important decisions - especially ones that involve high-stakes infrastructure security impacting every employee in the organization. But worry not; this is why we’re here!
What is SSO? How it works?
I’ll try my best to explain the SSO concept without any jargon.
Single sign-on (SSO) is an authentication method that allows a user to securely sign in to multiple applications and services using just one set of credentials, e.g., username and password. The SSO system is made to work through an identity provider where the user’s identity and credentials are anchored. This identity provider interacts with all applications and services by exchanging trust certificates or tokens containing the identity information needed to authenticate the user. This is how it works:
When a user tries to log in to any website, the service provider sends a token to the identity provider with some information (mainly the user’s email address) to authenticate the user.
Suppose the identity provider has already authenticated the user. In that case, a confirmation token will be sent back to the service provider, which contains the user’s identity, and they’ll be logged in.
If the user is not authenticated, they’ll have to enter their credentials once, and upon validation, the identity provider will send the confirmation token to log the user in.
Now, this same log-in workflow can stay consistent for the user across all different applications and services that are tethered to the identity provider.
Evolution of SSO protocols
There are many SSO protocols (heads up - jargons!) - there’s LDAP, there’s SAML, there’s CAS, and then there’s OAuth - I promise we aren’t making these terms up.
They all represent different authentication protocols that have been around since the early 90s! Here’s a timeline of when they were created:
Every authentication protocol has a specific use case and, like everything else in the world, has both pros and cons. In the next section, let's look at all these different protocols and their benefits and tradeoffs:
Lightweight Directory Access Protocol (LDAP)
Even though LDAP is often clubbed into various authentication protocols, it really is a directory and access management protocol that defines how one should talk to a directory server. Most systems use LDAP to talk to a directory, retrieve user accounts, verify them and retrieve attributes associated with them.
Pros: Works well for on-premise authentication.
Cons: Extremely complex to set up and painful to maintain. Users have to set up new accounts for external services.
Security Assertion Markup Language (SAML)
SAML is an XML-based framework for describing and exchanging assertions that applications across security domain boundaries can trust. e.g., a typical assertion from an identity provider (IdP) would convey, “This user is John Doe, with the email address of john.doe@example.com, and was authenticated using a password mechanism.” Depending on its access policies, a service provider (SP) could use this information to grant John Doe web SSO access to local resources. [Spec]
Pros: Ability to control employee access across different services and domains, including external ones.
Cons: Due to the complexity, SAML has been mostly confined to enterprises and academia.
Central Authentication Service (CAS)
Central Authentication Service (CAS) is a single sign-on protocol where the authentication process can only happen on the CAS server. Applications that authenticate with CAS never see the user’s credentials.
Pros: Credentials are less likely to get compromised as applications never see them.
Cons: CAS leaves the authorization to the application itself [ref].
OpenID
OpenID was created to solve SSO for non-enterprise end users. It allowed end users to specify URLs as their identifiers. e.g., An end user claiming http://www.example.com as their identifier would include a link to their IdP in the HEAD section of the HTML document served by http://www.example.com. OpenId was never widely used but led to the evolution of OIDC. [spec]
Pros: The authentication is offloaded to the OpenID provider, and their security systems can be leveraged. Anyone can become an OpenID Provider without requiring third-party registration/approval.
Cons: The support for OpenID extensions is inconsistent from provider to provider. This makes it difficult and cumbersome to implement. Moreover, OpenID’s relying parties can only be web apps.
OAuth
While SAML and OpenID enabled end users (Resource Owners) to SSO for protected resources, there was still no mechanism to authorize applications to directly access users’ resources without the end user's credentials. OAuth enabled this by verifying not only the end user’s authorization to access the resource but also the application's identity that makes the resource request. e.g., applications using Google’s API often rely on OAuth to act on behalf of the end user. [spec]
Pros: Uses API calls extensively, which is why mobile applications, modern web applications, game consoles, and the Internet of Things (IoT) devices find OAuth a better experience for the user
Cons: OAuth leaves out the decision of several specifics to implementors, e.g., token types, vulnerabilities, and interoperability issues. OAuth was not designed as a general end-user authentication service and required proprietary add-ons.
SSO is flawless! No, really, not one issue with it.
Now that we understand all the different protocols let’s look at why SSO as a system has been the best thing since sliced bread (NOT!).
There are a lot of advantages to SSO, and no one denies that, but it does come with a fair share of problems and implementation challenges.
Onboarding so good, we feel like hiring people all the time!
Offboarding so good, we feel like firing people... Oops!
Common Narrative
SSO relieves the pressure on IT help desks while onboarding and off-boarding employees. SSO streamlines the onboarding/off-boarding process by reducing the number of individual access requests from employees. Sure! All of that seems excellent, but you should also know some of the issues that come with it.
What they don’t tell you
When SSO is used to provision users in downstream apps, that process becomes opaque to the organization. This sometimes results in users having residual access to downstream apps despite being removed from the SSO directory.
The SSO mechanism, especially OAuth, relies on access tokens and refresh tokens being exchanged between the identity provider and the service provider. Refresh tokens should ideally have an expiry date on them. But the problem arises when expiry is not configured correctly, and the downstream application has to set a default in that scenario. Often the default value is never set, and hence the token never expires.
Now, if the user is removed from the identity provider but NOT explicitly logged out, they might still be able to access the downstream application. If you want to gauge the scale of this problem, organizations with more than 1,000 employees use 150+ SaaS and infrastructure applications. The higher the number of apps, the more susceptible the organization is to encountering this issue.
So secure! Is this Fort Knox or what!
Common Narrative
SSO reduces the number of attack surfaces because users only log in once every day and only use one set of credentials. If login for each user happens only through a single set of credentials, the organization's security posture improves.
What they don’t tell you
The irony of implementing SSO is that the very thing that makes it secure is also a huge security risk!
SSO is more concerned with providing access than with restricting it. Login credentials are a major focus for external attackers - 61% of data breaches involve credential data.
If a user’s SSO credentials get compromised, the hacker or intruder can access all applications, environments, and services. SSO is usually associated with critical resources so the resulting damage will be pretty bad for an organization.
IT teams are just loving resource management through SSO!
Common Narrative
SSO provides a unified way to manage all your apps and services through one dashboard. It provides IT teams with an easy way to keep track of all different employees and the apps and services they have access to.
What they don’t tell you
SSO introduces a single point of failure in the organization. If, for some reason, the SSO service goes down due to the identity provider going offline, users lose access to all apps, app servers, and services. It goes without saying that this situation will be highly disruptive to any organization.
The roadmap for implementing SSO is long. The process to configure each app with an identity provider consists of many-many steps and can take weeks, if not months, per application.
Moreover, SSO cannot be applied everywhere – it is mainly used with web, mobile, and desktop applications. However, SSO does not support infrastructure resources like VMs, Kubernetes clusters, and databases.
SSO is brilliant for access management!
Common Narrative
With the move to the cloud, employees are using more and more apps in the workplace. Requiring separate usernames and passwords for each app is a huge burden for employees and, frankly, is unrealistic. Signing in once saves time, thus improving employee productivity. Since 68% of employees switch between ten apps every hour, eliminating multiple logins can save a company significant time and money. Single sign-on reduces that cognitive burden, not just for employees but also for IT teams.
What they don’t tell you
The principle of least privilege required for various compliance measures commands users to have minimum access to data, applications, and systems required to do their job. If they need elevated access, it should be done through separate credentials. Both these things cannot be achieved easily in SSO as the setup entails giving access with a single authentication.
Moreover, SSO might be good for authentication but doesn’t work for authorization. Enterprise systems like SAML leave the authorization to the individual apps and services. So much of the groundwork is needed to assign the correct privileges to each employee, which still happens in the downstream resource.
Make SSO great again!
The ideal way to set up SSO is to use it with an access control plane, especially for critical resources. This setup solves some of the significant shortcomings that are mentioned above. Let’s look at them one by one:
Wider reach
An access control plane can help enable SSO for infrastructure resources that wouldn’t be possible otherwise, e.g., databases, VMs, and Kubernetes clusters.
Security & Auditability
An access plane can help improve the security posture. Since the access plan contains multiple access proxies in a federated setup, no single-point attack vector can bring down the resources.
Additionally, an access plane enables auditability into the resources. This helps organizations detect any attacks from internal or external sources.
Authorization & Permissioning
An access plane can help automate authorization and assigning roles while onboarding and offboarding people. Moreover, the access plan keeps checking for residual access and ensures users are correctly deprovisioned from downstream apps and services.
Efficient Implementation
Lastly, having an access plane streamlines the SSO implementation. Since the access control abstracts the downstream resources, the service configuration has a minimal footprint.
There’s no denying that SSO is a critical technology and is here to stay. Every organization, at some point in its journey, would need to implement SSO. However, what’s important is to understand all the different challenges and nuances while implementing SSO so that you can solve all its limitations.
