Let’s get this out of the way: SaaS vendors that lock Single Sign-On (SSO) behind enterprise-only plans do a disservice to their customers and the industry. No wonder the US government’s Secure by Design Pledge expects vendors to provide SSO in baseline versions of their products.

But this article isn’t complaining about vendors who don’t do this–it’s more pragmatic than that.

What should you do with the products that you had to purchase without SSO? Let’s understand the role that SSO plays in modern defense architecture. Then, we’ll cover how to implement similar security controls without such a centralized control mechanism.

Controlled Entry Points as Defense Tactics

First, why is SSO so important to security and IT professionals? It acts as a chokepoint. Defenders have historically used choke points to control attackers. Numerous examples include:

• Battle of Thermopylae (480 BCE): A small Greek force defended the narrow Thermopylae pass against the much larger Persian army. The location allowed the Greeks to inflict significant losses.
• Battle of Stirling Bridge (1297): The Scots positioned themselves near the narrow Stirling Bridge, which allowed them to overwhelm the English forces as they crossed the bridge in small groups.
• Battle of Morgarten (1315): The Swiss Confederates ambushed the Austrian forces in a narrow pass between a lake and the mountains. The advantageous terrain allowed the Swiss to achieve a decisive victory.

Just as historical defenders leveraged choke points to concentrate their resources and control the flow of attackers, SSO centralizes authentication, creating a single, controlled entry point for accessing multiple systems.

SSO as a Control Funnel

Centralizing authentication through an SSO provider allows efficient enforcement of security measures, account management, access monitoring, and attack surface reduction:

• Enforce security measures: Enable multi-factor authentication (MFA) to help prevent attacks such as those that affected Snowflake customers in May 2024. Control which authentication factors are available, enforce password complexity, configure session duration, and manage credential resets.
• Manage user accounts: Automate user provisioning and deprovisioning via SSO-provided SCIM capabilities. Automatically assign roles according to personnel needs. Gain visibility into product utilization for licensing requirements.
• Monitor access: Use the SSO provider’s anomaly detection to flag suspicious login attempts, such as those that occur from unexpected locations or malicious infrastructure. Direct logs to a centralized location (SIEM) for analysis, correlation, and forensics.
• Reduce the attack surface: Expose a single, fortified login mechanism provided by the SSO vendor, reducing reliance on individual SaaS vendors' security practices.

These benefits don’t apply to the SaaS products onboarded without standards-based SSO, putting defenders at a significant disadvantage.

Compensating for the Lack of SSO

To define baseline SSO expectations organizations should:

1. Formally require SSO (and SCIM) for all SaaS purchases.
2. Communicate that policy to internal purchasers and vendors.
3. Educate purchasers to negotiate SSO capabilities when buying and renewing products.
4. Create a process for approving exceptions when SSO is unavailable. 

When granting an exception to buy an SaaS product without SSO support, organizations must compensate for the loss of security measures by assigning responsibilities may be assigned to IT, cybersecurity teams, or business units. Define expectations for:

• User account settings: Acceptable 2FA factors, password requirements, session duration expectations, etc.
• Provisioning and Deprovisioning: Steps for creating user accounts with the right privileges and disabling the accounts when employees leave or no longer need the product.
• Security Monitoring: Detecting attacks and configuration weaknesses, reviewing in-app security logs, or directing events to the organization’s SIEM.
• Centralized Oversight: Determining whether the appropriate security responsibilities for securing the product are being followed.

Organizations should recognize that they take on these burdens when purchasing SaaS products without SSO. If they cannot commit to these security measures, they accept the increased risk that the SaaS product will be compromised or look for an alternative product that offers SSO.

The absence of SSO in SaaS products poses significant security challenges. Organizations can tackle them by enforcing SSO policies, negotiating for SSO capabilities, and implementing compensating security measures. By taking these steps, you can maintain robust security even without centralized access control, ensuring your SaaS environment remains secure and manageable.