The pressure on SaaS vendors and others to address issues of identity is being driven by the fact that anyone can build a SaaS application and put it out there and then anyone in a corporation can whip out a credit card and sign up to use it.
Thanks to such incremental, department-level purchases, SaaS applications rapidly proliferate and create what has been referred to as “SaaS sprawl.” Eventually the business forces within the enterprises consuming these SaaS applications say, “We need some ability to control this,” and the controls they want are identity focused. So they begin asking SaaS vendors to support things like federated identity, compliance and audit reporting, and better authorization systems.
The problem is that the SaaS vendors want to focus on their content. They have a certain level of expertise and they want to write the simplest yet deepest, most valuable application in a particular niche. They don’t want to worry about the quirks of the SAML 2 protocol. (Not to mention the fact that holding user accounts and managing security for their clients is more of a liability than anything else.)
Now, we recently conducted a survey where we asked SaaS vendors who should implement these identity measures. A third said, “We should OEM it;” a third said, “We should handle it ourselves;” and a third said, “The hoster should provide it for us.”
In other words, about two thirds said they don’t want to do it themselves, and I would maintain the other third hasn’t tried it yet.
On the OEM front, the SaaS vendors could partner with someone to handle identity and security. While some of the larger SaaS players, like Salesforce and Google, wouldn’t want to say, “powered by NetIQ” - they’d want to say they manage this themselves - for a lot of the smaller SaaS vendors, it might be to their advantage to say, “We didn’t roll our own. Security protocols are hard. We went to a trusted name and got them to implement it for us.”
Nevertheless, I think the better idea is selling to the hosters to enable the SaaS applications platform-wise to manage identity. Not only would this solve a problem for the SaaS folks, it would solve a big problem the hosters have: stickiness. You see, people can move an application from one host to another without much trouble. The hosters want to be able to hold on to relationships with specific SaaS customers and the idea of identity services is one of the stickiest things possible. Why? Because where people have their user accounts is a very sticky thing.
For proof-of-concept, you need look no further than Google. A while back people were asking, “What’s Google doing with all these email accounts? Why are they hosting email and not even advertising to people? How does that help?” The answer was pretty simple: It gets them mission-critical identities. So now they’ve started to turn around and enable those accounts to be, via OpenID, an identity source that can automatically access the applications in their marketplace built on Google App Engine.
Which means that SaaS vendors writing apps on Google App Engine have identity management handled for them. Google has realized that, as a platform play, identity is incredibly sticky and valuable. Salesforce has recognized the same thing and begun extending all the SAML 2 capabilities and account information of Salesforce to all the SaaS applications built on Force.com.
Isn’t it time that other hosters got in the game?
Jun 07 2010, 07:00 PM
Filed under: Security, Compliance, Google, SaaS, Identity Management, Identity and Access Management, SaaS Sprawl, OpenID, Audit Reporting, Federated Identity, Salesforce, SAML 2, DaleOlds, Security Web