SSO in Web Services Using SAML


Web Services provides a standard mean of interoperating between different software applications running on a variety of platforms. The simplest web service consists of a SOAP message for communication and a WSDL for web service description.

Web services use XML extensively which are very well understood technology. WSDL document defines services as collection of network endpoints or ports.

One of the main problems in distributed Web Services is security standards. Due to different platforms the interpretation of security information has different meaning in different security context. For instance if a J2EE application try to exchange security information with a COM+ application, the data sent by J2EE application will not be recognizable to COM+.  The other problem in distributed Web Services application is the capability for single-sign on. Security Assertion Markup Language (SAML) is a standard proposed by OASIS to solve problem like security information exchange and how Single Sign on capabilities be provided within distributed web services application.


Exploring SAML:

SAML is a set of specifications used for transferring information like user authentication, entitlement, and attributes to identity provider (IP) which can authenticate the user and allow access to resources on a server provider.  In SAML a third party which is identity provider will assert the authentication information provided by the consumer and will return SAML assertion which can be passed with any incoming request to the target or resource provider which will identify the assertion and allow access to the corresponding activity.

By obtaining the assertion from identity provider consumer can pass it with any request. The same assertion can be used universally and by any part of application which is a step forward to interoperability in security context.

All the security services which implemented SAML are able to interpret security information transferred by one service to another which makes SAML one of the most accepted solutions for Web Services Security.  The Assertion generated by identity provider can be used by consumer as long as it is trusted by target or service provider. The Service Provider can accept the principal an allow authentication.

SAML provides three types of assertions:

1. Authentication assertion

2. Authorization decision assertion

3. Attribute assertion.

Authentication Assertion


The authentication information is received by identity providers which process this information and authorization assertion is made along with authorization decision and attributes assertion.  Authentication Assertion is composed of the identity of issuer and the principal, the period for which the assertion will be valid and some creation time information. It also input some information about the provider system and validation time etc.

The following is the Authentication Statement Schema

<element name=”AuthenticationStatement”  type=”saml:AuthenticationStatementType”/>

<complexType name=”AuthenticationStatementType”>


<extension base=”saml:SubjectStatementAbstractType”>


<element ref=”saml:SubjectLocality” minOccurs=”0”/>

<element ref=”saml:AuthorityBinding” minOccurs=”0”



<attribute name=”AuthenticationMethod” type=”anyURI”


<attribute name=”AuthenticationInstant” type=”dateTime”





Attribute Assertion


The attribute assertion contains attribute authority of the resources provider. Policies which are used to determine what resources are allowed for a particular assertion type. Attribute assertion is passed to policy decision point which make the decision based on it. In attribute assertion policies are attached to Subject element. Here is the schema definition of Attribute Assertion

<element name=”AttributeStatement” type=”saml:AttributeStatementType”/>

<complexType name=”AttributeStatementType”>


<extension base=”saml:SubjectStatementAbstractType”>


<element ref=”saml:Attribute” maxOccurs=”unbounded”/>








Authorization Decision Assertion


 Authorization Decision Assertion is responsible for making the decision about a principal if it have  permission for the requested resource. The requester pass Authentication and attribute assertion .  It comprise of policy decision point (PDP)  and policy enforcement point(PEP) .

A fragment of the authorization statement is presented below:

<element name=”AuthorizationDecisionStatement”


<complexType name=”AuthorizationDecisionStatementType”>


<extension base=”saml:SubjectStatementAbstractType”>


<element ref=”saml:Action” “maxOccurs =”unbounded”/>

<element ref=”saml:Evidence” minOccurs=”0/>


<attribute name=”Resource” type=”anyURI” use=”required”/>

<attribute name=”Decision”

type=”saml:DecisionType “use=”required”/>






Exploring SSO in SAML Perspective:

One of the main issues with distributed Web Services application is keeping the logged in information across different applications due to its distributed nature. The consumers have to remember different security credentials for different application. One of the possible solutions to this problem is Single Sign-on. The basic concept is to separate the Security information to another service and can be used across the system. All security information will be stored on different server which will act as a wrapper on top of any business application that need any security credentials. SSO can be hosted as a standalone Web Service.

In SSO the authenticated party or consumer first call the SSO server and request for Security token by providing the authentication credentials. SSO server will do validation and issue a security token. The authenticated party can use these token with any system that implemented or support those security credentials. The service provided will verify those authentication tokens and allows access to resources. The below shows a simple scenario.

Through SAML, a customer can login to one System and the authorization information is passed to the next Service. This makes it very easy for related system to exchange trusted information about customers. SAML provides the base for Single Sign-On where user need to login once and the Systems internally will pass along all the security credentials to next service.

SAML can be transferred through different protocols. For instance it can be passed embedded within a SAOP message on HTTP. SAML defines request and response protocol which enable the service provider to allow or deny a             ccess to a particular resources based on the Subject entity.

Mostly of the time in distributed Web Services environment SAML is used on a separate server which is responsible for issuing the SSO Authentication services. The main benefits of this architecture are the following.

•             Security infrastructure is hidden in a separate server which makes maintenance and monitoring easier.

•             SSO implemented through SAML can be transferred as SAOP message and it can be deployed as a separate web service which makes the implementation API accessible like any other hosted web services.

SAML standardized the request and response messages that are transported from third party to a requester. SAML calls the protocols for transporting the messages to and from the authorities the SAML bindings.

In the above diagram it is clear that each the requester want any interaction with the any service and if authentication is needed, the requester has to authenticate itself with SSO server. Another approach is keep valuable information in the security token itself which the requester can pass whenever there is a need for authentication.

The token will contains information like authentication and authorization and information about SSO Server like sign by a particular SSO server which is recognized by the Service provider. The described scenario is outlined in the following diagram:


SAML contains assertion statements about subjects that SSO Server will transfer as a SOAP message. Client can make request to SSO Server and it will response a message with SAML assertion. The client can use this assertion and call the Service provider which can check proof of origin and decide to allow access to resource or not.

One of the major complaints of end user is the usage of different password for different application. The users always want to have one password for all application and the application should be capable of enforcing the security measure across multiple domains.

The major hurdle for achieving Single Sign-On across different distributed application is that authentication credential used by one application is different from another one and not understood by the any other application. Given the widespread acceptance of SAML Single Sign-On can be achieved. SAML Assertion can be passed from one application to another without the need to ask the user to authenticate again.

A Simple Process Flow of Single Sign-on Using SAML:



•             User Create an account in Identity Provider.

•             Using browser the user attempt to access a resource provided by Service Provider.

•             Service provider will send the request to identity provider.

•             User will request Identity Provider with SAML authentication request

•             Identity Provider will responds with SAML Assertion embedded in the form of SOAP message.

•             The User can use this assertion with any request to the Service Provider which makes the decision to allow access to resource.

SAML Single Sign-on For Google Apps Use Case:

Google Apps Services can be invoked using third party Identity Provider based on SAML.  It offers SAML based Single sign-on functionality in which third party provides authentication for the end user.

Below diagram show how end user can use Google Applications by using third party  SAML based SSO.


Due to the diverse nature of Web Services implementation it is very hard to standardize security framework which will provides functionality like Single Sign-on. SAML defines standards which can be used to integrate SSO functionality in distributed Web Services applications. SAML is widely accepted standard which makes it the ideal choice for SSO implementation.




2. Mastering web services Security By Bret Hartman & Donald J. Flinn & Konstantin Beznosov & Shirley Kawamoto





2 responses to this post.

  1. Posted by Mark C. Wallace on January 13, 2011 at 12:36 pm

    I’m interested in the topic and this looks like a very good article; unfortunately the formatting makes it very difficult to read.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: