Archive for the ‘Web Services’ Category

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





External Versus Internal Web Services : A comparative study

  • Introduction

Web Services is a set of standards to support interoperability between 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. There are abstract definition for operation and messages that will be used in services provided. WSDL also define what transport protocol will be used for a particular service endpoint through binding section. The last section is service Here the concrete service endpoint is defined. Endpoint address is tied to location. From WSDL the service input and output can be determined.

To use third party or external web service UDDI can be queried . UDDI (Universal Description discovery and integration) is a directory service where any web services carrier can publish their services. Many companies have implemented UDDI as private or public registry services. It is important for web services carrier to publish their web services on UDDI. The consumer can discover the services by checking the UDDI white pages (which have the carrier name, address etc) ,yellow pages ( which contains industry information ) and green pages ( which contains the technical information about the service).      

Each organization must analyze the risk involved in choosing between implementing their own web services versus consuming third party web services. The risk to be kept in consideration for instance will be accessibility, security ,migration and  implementation.


External Web Services

As the web service market continue to grow there are various web services available that can cater many business needs. Depending on functional objectives ,it may be more efficient to use exiting web services that fit the requirement precisely. External web services are easy to use. The only thing need to discover the service, read the technical document if it match the requirement and obtain access to WSDL document. Most organization have secure access to WSDL resources a contract agreement is needed to get the access. Depending on the consumer platform many tools are available to generate code from WSDL. External web services are a lot cheaper and more reliable since the carrier are specialized in the services they provide.

.  Internal Web Services

There are certain requirement that can’t be fulfilled by using external web services. There could be several motive for create internal web services. It could be security the organization can’t allow private data exchange with the third party. If the organization is too big they might have a lot of internal system that need to interact with each other internal web services is the solution in that case. Implementation of internal web services could be very costly creating a new process from scratch from the requirement need a comprehensive study of the requirement.

Evaluation Criteria:


.    Requirement and Guideline:

Utilizing external web services could be easy to utilize but since it is very generalized it may not meet organization requirement. External Web services are not specific to a specific customer problem but rather a common solution whereas Internal web services are created from starch conforming the requirement.

.     Implementation Cost:

Using external web services can reduce the cost dramatically. For a small organization it is not beneficial to create their own web services which don’t have many different platforms. The implementation risk will be very high for internal web services.

.    Time and Resources:

Internal web services takes more time compare to External web services Since many stuff need to be created from scratch. For external web services only implementation is needed.

.    Publishing

Internal software doesn’t need to published in any registry .They can be used anytime if you have access to WSDL(web service description language).For external web services publishing is important at any registry for instance UDDI( Universal Description discovery and integration).

.    Existing infrastructure

Internal web services are very useful for larger organization. Information can be gathered from variety of application written on different platforms. For small organization which don’t have that many system external web services is a good option.

.    Security

By using external web services there is potential security risk. Data misuse and reliance on third party with whom there may be no contractual agreement. Any sensitive data should not be exchanged between transaction when using external web services.

.    Change and Update

The problem with external web services is that if there is any new build or release. They need to inform all the consumer of the service regarding that change.

  • Conclusion

If an organization have general requirement and the information required is only for information gathering then external web services is the best option. If an organization have many different system and to transform it to a unified system in that case internal web service is required. By using third party web services there is security risk any sensitive data should not be exchanged when using external web services.

  • References

.Webservices architecture