Single Sign-On (SSO) serves as the linchpin connecting corporate networks, facilitating seamless access to various web applications without the need for repeated login credentials. However, there are several untold challenges that Identity Access Management and Cybersecurity experts face every day across the world in maintaining a stable SSO infrastructure. Within this article, drawing upon my extensive experience in Identity Access Management and Security, I aim to provide a comprehensive walkthrough for establishing the necessary infrastructure for a stable SSO implementation that works consistently and avoids surprise failures.
What is SSO and How Does it Work?
SSO makes life easier by letting users hop from one app to another with just one click, no need to type in their login details every time. It’s like having a magic key that unlocks multiple doors! Basically, there are two main players in this game: the Identity Provider (IDP) and the Service Provider (SP). The IDP is where you’re already logged in – your starting point, while the SP is where you want to go – your destination. And when it comes to SSO, there are two popular ways it can happen: IDP-initiated SSO and SP-initiated SSO.
Figure 1: Different Types of SSO Mechanisms
In both cases, the IDP issues a Security Assertion Markup Language (SAML) token containing a user identifier, which the SP verifies for authenticity. Using this identifier, the SP finds the user in its database and grants access for login.
Key Components of SSO
User Provisioning
For a seamless SSO transaction to occur the user’s identity must exist in both the systems. This can be done either through a proactive database sync between the two software systems ahead of time or new users can be provisioned on demand when a SSO request is received by the Service Provider (also called Just In Time provisioning).
SAML (Security Assertion Markup Language) Token Verification
The SAML token includes a signature, user ID, and timestamp for token generation. A private-public key shared certificate generates the signature, requiring an exchange between IDP and SP administrators beforehand. The IDP holds the private key, and the SP holds the public key. Upon receiving a SAMLResponse, the SP verifies the signature using its public key to authenticate the token. Timestamps are also examined to prevent replay attacks by malicious actors who may acquire the token through a man-in-the-middle attack.
Untold Challenges Faced in Practice
Inconsistent Terminology & Incompatible Signatures
Various SSO vendors offer solutions, with some firms opting to develop their own. This diversity results in inconsistent terminology across vendors. For instance, the URL receiving the SAMLResponse token (step 2 in Figure 1) goes by various names like Assertions Consumer URL, SAML Post URL, and SAMLResponse URL. Moreover, different vendors employ different methods for signing the SAMLResponse token. While some sign only the payload (user identifier, timestamps), others sign the entire token. If the signature expectations of the Service Provider (SP) and Identity Provider (IDP) don’t align, SSO transactions can fail.
Corporate Firewall Misconfiguration
Corporate networks restrict traffic to known IP ranges, causing SSO failures if an IDP or SP’s IP falls outside the allowed list. Additionally, proxies in corporate networks sanitize web traffic, sometimes resulting in incomplete or missing request payloads during exchanges between IDP and SP, further impacting SSO functionality.
Clock Drift
Clock Drift is a phenomenon where a server’s clock goes out of sync with natural time and begins to lag. If either SP or IDP has servers that have drifted, then the timestamps published in the SAMLResponse token appear stale to the SP, causing it to suspect malintent and reject the token, in turn causing the SSO to fail.
It is important for the SP and IDP’s administrators to know and account for these factors before SSO transactions can occur in order to save countless engineering hours spent in troubleshooting SSO failures.
Other Often Ignored Facets of Supporting SSO
Improper Certificate Management
The private-public key pairs exchanged between IDP and SP have expiration dates for security reasons. When a certificate expires, it causes SSO failures due to invalid signatures and leads to board scale service unavailability. To prevent this, certificates must be tracked, renewed, and deployed before expiration. Storing certificates externally, rather than within the application, allows for easy replacement and validation. Caching certificates minimizes I/O for fetching, with the cache invalidated upon expiration.
Lack of Troubleshooting Tools
SSO is essential for onboarding new partners, typically occurring as the final step in the sales cycle. Onboarding is often managed by non-technical personnel, so providing self-service tools empowers them and streamlines the process. A web-based interface tracking SSO requests and responses, and highlighting issues, facilitates smoother onboarding.
Conclusion
Single Sign-On accelerates business partnerships and rapid adoption of online services globally. Yet, managing the SSO infrastructure can be complex. This document outlines measures to simplify SSO administration worldwide.
About the Author
Chetan Honnenahalli is a Cybersecurity and Identity Access Management (IAM) expert with more than 15 years of industry experience in companies such as American Express, Zoom and Meta. Chetan can be reached online at https://www.linkedin.com/in/hschetan/