When accessing different applications owned by different organizations, having to authenticate everytime you go from one application to another is annoying. Not only is it time consuming, but you also have to remember multiple passwords, which are often lost.
Single sign on is the ability to authenticate once and be able to move between applications seamlessly using the authenticated identity.
Within an intranet or between applications that are under the control of one development organization, single sign on for web applications can be easily implemented by generating a sessionid and passing it around using cookies. However, such a solution is proprietary and will not work if you need to leave the intranet and access other applications on the cloud. To interoperate with applications on the cloud, a more standards based solution is required.
A related concept and benefit is federated identity. Organizations can agree to a common name to refer to users. The user and his attributes needs to be created only in once place and others can refer to this information.
In this blog, we briefly examine two popular protocols that can be used for single sign on on the cloud: SAML and OpenId.
OpenId
The problem OpenId solves is that you as a user do not have to maintain and provide a password to each and every site you visit.
You maintain your password or other identifying credential with one provider known as the OpenId provider.
The website or application that you visit and that requires proof of who you are, relies on the OpenId provider to verify that you are who you claim to be. This is known as the relying party.
The basics of the OpenId protocol are:
1. You visit a web application (relying party) and enter an OpenId
2. Based on your OpenId, the relying party determines who your OpenId provider is.
3. The relying party redirects your request to the OpenId provider.
4. If you are already authenticated, this step is skipped.
The OpenId provider authenticates you by asking for a password or other information. The provider warns you that the relying party is requesting information about you.
5. The request is redirected back to the relying party where you are shown the URL you were trying to access.
The protocol does not require providers or relying parties to be registered anywhere. It uses plain HTTP requests and responses. The protocol messages are plain text key value pairs. The protocol works well with modern "Web20" AJAX style applications.
The OpenId protocol originated from consumer oriented websites such as Google, Twitter, Facebook etc and that is where this protocol is popular.
The OpenId specification is described at OpenId specification
There is a java implementation of OpenId at openid4java
SAML (Security Assertion Markup Language)
SAML is a XML based protocol that enables web based authentication, authorization and single sign on.
SAML involves a relying party requesting an assertion and a SAML provider responding with the assertion.
Examples of assertions are :
Authentication Assertion : This user was authenticated using such and such method at time t.
Attribute Assertion : This user has a title supermanager.
Authorization Assertion : This user has permission to delete file xyz.doc.
A typical SAML interaction would be as follows:
1. A user tries to access a URL or a web application which is the relying party
2. The relying party creates a SAML authentication request.
3. The relying party redirects the users browser to a SAML provider. Embedded in the request is the SAML authentication request.
4. The SAML provider evaluates the SAML request and authenticates the user.
5. The SAML provides returns a SAML authentication response to the user browser.
6. The browser forwards the SAML response back to the relying party.
7. The relying party verifies and interprets the SAML response.
8. If the response implies successful authentication, the user is redirected to the URL, he was originally trying to reach.
SAML has the concept of profiles. The interaction is different based on the profile. The interaction above is the Web SSO profile.
SAML has its origins more in enterprise software, in web services, in B2B communication and is from the early 2000s when XML was very popular. In fact SAML1.x had only a SOAP binding.
The SAML specification is at SAML Specification
There is a SAML implementation at OpenSAML
Which protocol should I use ?
OpenId is a simpler protocol. But has SAML has more features.
OpenId supports discovery of the OpenId provider. Using SAML has generally required expensive SAML projects.
OpenId supports only service provider initiated SSO. You go to a service provider web site and they need authentication. They start the conversation with the OpenId provider. SAML can also support identity provider initiated SSO. You are authenticated into your companys portal. Your company has a partner travel website for business travel. With SAML, you can go from your companys portal ( SAML provider) to the partner website ( relying party) without needing reauthentication.
SAML has been around longer than OpenId. SAML is more popular in the enterprise where as OpenId is more popular in consumer oriented applications.
Both OpenId and SAML rely on external transport layer security protocols such as SSL for the security of protocol messages.
If you are starting a new website and want to accept users from other popular sites such as google or twitter, you might consider OpenId. However if you are an enterprise and you want your authenticated users to access your partner sites without re-authentication, you might need SAML.
In summary, SAML is a feature rich protocol more popular in the enterprise. OpenId is simpler protocol with some limitations.
