Want to enable Single Sign-On (SSO) in a SaaS application that your organization uses? Be prepared to pay for this “privilege” as the fees will likely be more than you think.
Not long ago, many vendors charged extra to enable HTTPS access to their products, considering this an enterprise-only feature. While this form of charging for baseline security mechanisms is now in the past, many providers today similarly treat SSO as a luxury item. By making SSO available solely in higher-priced bundles, such vendors keep this essential security measure out of reach of small and mid-size organizations.
The Broad Need for SSO
SSO, paired with centralized identity management, is an important and broadly needed security measure, given the attackers’ increased focus on compromising user accounts. It’s also the cornerstone of the Zero Trust security architecture, which has been gaining steam among companies of all sizes.
Zero Trust recognizes that modern IT practices increasingly rely on access to resources outside the company’s internal network. This philosophy encourages organizations to focus security decisions on the user’s identity, instead of the network on which the user appears to reside. That means guarding resources by authenticating the user, confirming that the user has permission, and validating the context of the request before granting access.
Given the prevalence of breaches that involve compromised user accounts and the growing adoption of the Zero Trust mindset, security practitioners encourage companies to move toward SSO and centralized identity management. This entails setting up user accounts in a unified system, such as G Suite, Azure AD, Okta, OneLogin, Duo, and other identity providers. The organization can then configure its SaaS applications to delegate authentication (and some aspects of authorization) to the identity provider.
Such SSO--often powered by the SAML standard--benefits both the organization and end-users. With SSO, end-users appreciate having fewer passwords to remember, and the organization improves its practices by having a single tool to:
- Create user accounts and assign SaaS application access
- Disable user accounts and de-provision access
- Identify and investigate authentication anomalies
- Enforce policies, such as password requirements and multi-factor authentication
- Simplify password reset processes
These security and efficiency capabilities are desirable for organizations of all sizes, not just the large ones.
Identity providers are making SSO accessible even to companies without large staff or mature security practices. Some even offer a free version for small teams. However, to deploy SSO, the organization also needs to activate it in the SaaS products that it wants end-users to access. This is where a problem can arise.
The SSO Wall of Shame
Unfortunately, many SaaS providers enable SSO only for “enterprise” customers, making this essential security feature inaccessible to smaller organizations. Small and mid-size businesses don’t need enterprise features and cannot justify paying a premium solely for SSO. Unable to enable SSO, they have to resort to laborious, error-prone, and increasingly antiquated practices of maintaining dedicated user accounts in each SaaS product.
A representative list of vendors who charge a premium for SSO is on the SSO Wall of Shame site. It includes popular vendors such as Atlassian, DocuSign, GitHub, Slack, Box, and many others. As the site points out, by charging “2x, 3x, or 4x the base product pricing for access to SSO,” the vendors disincentivize its use and weaken security measures.
Price segmentation is a common business practice of charging customers differently based on their needs or perceived value. It’s impractical to correctly identify the needs of every customer to compute a truly individualized price.
Instead, vendors group similar customers into market segments and design a bundle of features appropriate for each segment. Each bundle is generally priced to maximize how much each segment values the features in their bundle. It’s is a valid, useful, and generally-accepted pricing mechanism.
The issue is that SSO is no longer useful for distinguishing between small and large companies because it’s turning into an essential measure for every organization. It doesn’t help with price segmentation anymore. Making it available exclusively in an enterprise bundle offers no benefit to the SaaS vendor and performs a disservice for non-enterprise customers.
SSO is Good for Vendors and Customers
If you’re a SaaS vendor that is hesitant to make SSO available to all your customers, consider the benefits of doing this to your business. You can:
- Minimize user identity data you have to store, secure, and audit yourself
- Position your product as enabling your customers’ Zero Trust journey
- Earn additional revenue if you decide to charge for SSO as an add-on
- Make your product more desirable than your competitors who keep SSO in a bundle
- Offer advanced authentication features through SSO providers without having to implement them yourself
- Receive positive publicity by explaining how you’re helping improve your customers’ security
Maybe the tide is starting to shift. Just recently, Zendesk announced that it’s bringing SAML-based SSO support to all plan levels. It’s time for other SaaS vendors to stop treating SSO as an enterprise-only feature. It’s time to make it available either as a baseline product capability or as an add-on accessible to even smaller organizations. It’s good for SaaS vendors as well as their customers.