Most people who are familiar with the concept of “the long tail” were introduced to it by Chris Anderson who addressed it in the context of consumer sales strategy, first in WIRED and subsequently in his own book. Anderson showed how long tail products have low demand but provide an opportunity for online vendors to be profitable selling a large number of unique items in relatively small quantities.
The long tail statistical phenomenon can also be applied to the enterprise space, where organizations must integrate their identity systems with SaaS providers to deliver Single Sign-On (SSO) for users and centralized control for IT. In fact, you can call this “heavy-tailed” distribution here, since significantly more SaaS vendors do not support standards-based SSO than those that do. According to Gartner, only about 25 percent of SaaS applications support SAML today. Several of the leading SaaS vendors charge their customers an additional fee in order to enable SAML to their service. The result is an environment where a standards-only approach will only enable SSO to a limited set of applications – reducing its overall benefit.
It will be years before this situation changes. Until Federation tools are built directly into the software stacks where these SaaS applications are deployed, there will always be a large portion of SaaS applications that don’t offer the capability. A big reason for this is that software startups are increasingly leveraging a lean, iterative, and incremental development methodology. As a result, convenience features like SSO are often not implemented until a SaaS vendor becomes successful and mature enough to have its customers demand that they support SAML. This challenge becomes an issue of business agility – where companies won’t be able to securely leverage emerging SaaS technologies until the SaaS vendors deploy SAML.
In order for businesses to have this agility they will need to be able to extend their identity systems to SaaS applications that do not have any standards-based SSO interfaces. This very same problem was solved in the client-server application space using an approach commonly called password vaulting, where a SSO system securely stores a user’s password and then fills in the login form on the user’s behalf when he accesses the application – often without ever seeing the password form submission. The user benefits from SSO and the enterprise can extend the reach of its existing identity infrastructure, all without requiring any changes to the application itself. Because we have limited influence over the SSO capabilities of SaaS providers, it is important to use the password vaulting approach to complement a standards-based approach for a solution for all of your applications.
To be clear, we’re talking about more than user convenience here; we’re also talking about security. Federated SSO provides more than the benefit of extending the convenience of SSO to users; it also bolsters security by extending the influence of your own user stores (e.g. AD, LDAP, SQL) to the cloud applications your users are accessing. This dramatically reduces the amount of orphaned accounts that occur when people change companies and roles within companies.