Enable Single Sign-On (SSO): Would you choose to enable Single Sign-On (SSO) in your organization’s Software as a Service (SaaS) application? So be obligated to pay for that kind of “privilege” because the expenses are much more highly probable that you believe. 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 was now in the past, many providers today similarly treat SSO as a luxury item. By making Single Sign-On (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 Single Sign-On (SSO)
Single Sign-On (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 Single Sign-On (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 Software as a Service (SaaS) application, to delegate authentication (and some aspects of authorization) to the identity provider.
Such Single Sign-On (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:
- Enforce policies, such as password requirements and multi-factor authentication.
- Simplify the password reset processes.
- Create user accounts and assign Software as a Service (SaaS) application access.
- Disable user accounts and de-provision access.
- Identify and investigate authentication anomalies.
Across enterprises of any and all dimensions, just not larger ones, these compliances and effectiveness strengths are advantageous. Identity providers are making SSO accessible even to companies without a large staff or mature security practices. Some even offer a free version for small teams.
However, to deploy Single Sign-On (SSO), the organization also needs to activate it in the Software as a Service (SaaS) product that it wants end-users to access. This would be where there might be a major issue.
The Single Sign-On (SSO) Wall Of Shame
Unfortunately, many Software as a Service (SaaS) provider enable Single Sign-On (SSO) only for “enterprise” clients, 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 Single Sign-On (SSO), they have to resort to laborious, error-prone, and increasingly antiquated practices of maintaining dedicated user accounts in each Software as a Service (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 disincentives its use and weaken security measures.
Price segmentation is a common business practice of charging clients differently based on their needs or perceived value. It’s impractical to correctly identify the needs of every client to compute a truly individualized price.
Instead, vendors group similar clients 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 been a valid, useful, and generally accepted pricing mechanism.
The issue is that Single Sign-On (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 Software as a Service (SaaS) vendor and performs a disservice for non-enterprise clients.
Single Sign-On (SSO) Is Good For Vendors And clients
If you’re a Software as a Service (SaaS) vendor that is hesitant to make SSO available to all your clients, 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 clients’ Zero Trust journey.
- Earn additional revenue if you decide to charge for Single Sign-On (SSO) as an add-on.
- Make your product more desirable than your competitors who keep Single Sign-On (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 clients’ security.
Maybe the tide is starting to shift. Just recently, Zendesk announced that it was bringing SAML-based SSO support of all plan levels. It’s time for other Software as a Service (SaaS) vendor to stop treating Single Sign-On (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 Software as a Service (SaaS) vendor as well as their clients.