Tuesday, December 30, 2008

OpenID, an utopia for SAAS?

My last blog entry was about testing SSO. Now I want to discuss another access method for web-based applications: OpenID.
If you would believe the open source community, OpenID simplifies your online experience by using one single username for different websites. This is also the most important difference with SSO.
With SSO you have access to different sites by 1 single action of giving your username and password. With OpenID you log in with your username (OpenID URL) and password at one site and still have to enter your username to access other sites. This mandatory logging in with your username is less user-friendly than the single action signing-in of SSO, but can also be safer, because a person has always to fill in his username to have access to the websites of the SAAS-application.
Then why is OpenID not a common thing in the SAAS-community?
First, there is the security threat of phishing. For a B2B environment this can be a disaster. But there is another more simple explanation why OpenID is not so common used with SAAS.
Because OpenID is a single set of credentials to all sites supporting it.
That means all OpenID-credited sites have 1-to-1 agreements with each other and that also the different OpenID-providers are active on the same sites with each OpenID-provider authenticating access to the sites by users with other OpenID-provider.
This race for federated login is going on right now.
Maybe nice for B2C, but when considering B2B there are other issues to look after. Using OpenID, you have access to different websites using 1 URL.
In a B2B environment (SAAS) an employee has access to different websites, but he is restricted in his access due to the role(s) he has in the company. An employee can have many roles, making it impossible to squeeze all these different roles and corresponding access rights into 1 URL. Or the directory of OpenID should be coupled to a built-in authorization module from the clients intranet as I previously discussed in my previous post on SSO.
But why then use OpenID and not the SSO-solution Distal?

You might already guessed I am not so fond of using OpenID as a means of access management for SAAS-applications. I think more work should be done here to avoid phishing and authorization-problems. For the last problem, Microsoft claims to have the solution by combining its Windows Cardspace with OpenID. But that leads again to a manufacturarID and not a OpenID. Though I like to see the development of OpenID and Windows CardSpace, which seems to me a challenge to test considering the scenarios Microsoft gives here.

In my opinion, considering authentication, OpenID is, in comparison to SSO, still far away from becoming a suitable access management method for SAAS.
OpenID still has a lot of issues to attend which are less in SSO.
When looking at authorization, both access management methods lack a proper and safe authorization-module, so external solutions have to be sought in for instance built-in intranet authorization modules (federated SSO) or Windows Cardspace (OpenID).
So it's unfortunately not only testing SSO or OpenID, SAAS is a 'network' and should be tested as such!

No comments: