2.1 Web Service
2.1.1 Concepts
Today, companies rely on thousands of different software applications each with their own role to play in running a business. To name just a few, database applications store information about customers and inventories, web applications allow customers to browse and purchase products online, and sales tracking applications help business identify trends and make decisions for the future. These different software applications run on a wide range of different platforms and operating systems, and they are implemented in different programming languages. As a result, it is very difficult for different applications to communicate with one another and share their resources in a coordinated way. To solve the problem of application-to-application communication, businesses need a standardized way for applications to communicate with one another over networks, no matter how those applications were originally implemented.
Web Services provide exactly this solution by providing a standardized method of communication between software applications. Specifically, web services are a stack of emerging standards that describe a service-oriented, component-based application architecture. With a standardized method of communication in place, different applications can be integrated together in ways not possible before. Different applications can be made to call on each other's resources easily and reliably, and the different resources that applications already provide can be linked together to provide new sorts of resources and functionality. Moreover, application integration becomes much more flexible because Web services provide a form of communication that is not tied to any particular platform or programming language. The interior implementation of one application can change without changing the communication channels between it and the other applications with which it is coordinated. In short, a Web service makes its
resources available in such a way that any client application, regardless of its internal implementation, can operate and draw on the resources provided by the Web service.[1]
2.1.2 Components of Web Services
Web services provide a standard way to expose an application's resources to the outside world so that any user can draw on the resources of the application. Web services are built on standard technologies such as HTTP and XML. All Web service messages are exchanged using a standard XML messaging protocol known as SOAP (Simple Object Access Protocol), and Web service interfaces are described using documents in the WSDL (Web Services Description Language) standard. These standards are all completely agnostic of the platform on which the Web services were built.
Web services are able to expose their resources in this generally accessible way because they adhere to the following communication standards [1]:
1. A Web service publicly describes its own functionality through a WSDL file.
2. A Web service communicates with other applications via XML messages.
3. A Web service uses a standard network protocol such as HTTP.
WSDL
A WSDL file provides a description (written in Web Service Description Language) of how the Web service is operated and how other software applications can interface with the Web service. Think of a WSDL file as the instruction manual for a Web service explaining how a user can draw on the resources provided by the Web service. WSDLs are generally publicly accessible and provide enough detail so that potential clients can figure out how to operate the service solely from reading the WSDL file. If a Web service translates English sentences into French, the WSDL file will explain how the English sentences should be sent to the Web service, and how the French translation will be returned to the requesting client [1].
XML and SOAP
XML messages provide the common language by which different applications can talk to one another over a network. To operate a Web service a user sends an XML message containing a request for the Web service to perform some operation; in response the Web service sends back another XML message containing the results of the operation.
Typically these XML messages are formatted according to SOAP syntax. SOAP, an acronym for Simple Object Access Protocol, specifies a standard format for applications to call each other's methods and pass data to one another. Note that other non-SOAP forms of XML messages are possible, depending on the specific requirements of the Web service. But, in any case, the sort of XML message and the specific syntax required can be found in the WSDL file, making the Web service generally available to any client application capable of sending and receiving the appropriate XML messages [1].
SOAP (Simple Object Access Protocol) is the method by which you can send messages across different modules. This is similar to how you communicate with the search engine that contains an index with the Web sites registered in the index associated with the keywords [2].
HTTP
To make it accessible to other applications across networks, such as the Internet and in-house intranets, Web services receive requests and send responses using widely used protocols such as HTTP (HyperText Transfer Protocol) and JMS (Java Message Service) [1].
2.2 Web Single Sign-On
2.2.1 Introduction
Single sign-on (SSO) is mechanism whereby a single action of user authentication and authorization can permit a user to access all computers and systems where he has access permission, without the need to enter multiple passwords. Single sign-on reduces human error, a major component of systems failure and is therefore highly desirable but
difficult to implement [3].
Single sign on is generally a process that allows the user to access multiple applications requiring authentication by passing his credentials only once. The user first authenticates to some trusted authentication authority and then is granted access to all the applications trusting that authority. The SSO systems usually preserve the state of the user for some period of time, so the user may repeatedly access these applications without the need to authenticate each time.
One of the main advantages of SSO systems is the convenience for the user. Another major advantage is security. There is only one place of authentication, which receives user's credentials. The applications only receive information about whether they may let the user in or not. Also, the user authenticates only once, so there is minimum transfer of sensitive information over the network, not to mention that SSO systems usually force the users to use secure communication channels.
Web single sign on provides SSO infrastructure for web applications. On community networks, there is often a number of web applications and services designed to aid community members and thus requiring authentication. In these cases it is convenient and secure to use a centralized SSO infrastructure bound to the central authentication authority. The most common example of such community networks are university campus networks and some of the most common web SSO systems were developed there [4].
2.2.2 Overview of Web SSO Functionality
There is always a central authority, which handles user authentication. It may support various backend authentication mechanisms like Kerberos, LDAP, relational database, etc. The central authentication server may provide also a user interface needed to retrieve user's credentials - usually a login form [4].
The applications in the SSO infrastructure are protected by special application layers called filters or clients. These filters, usually implemented as modules for the web server running the application, check if the user is authenticated before letting him to access the protected application. To perform these checks they need to communicate with the authentication server either directly or through redirects of the user's web browser.
There are two common scenarios for a SSO session: [4]
• login first - the user first performs login to the SSO infrastructure and then chooses a service to access
• application first - the user first tries to access a service, but because he has not been authenticated yet, the service redirects him to the login service and after a successful logon he is redirected back to the service
The use case [6], shown in Figure 2.2.1, described here demonstrates what the concept of web SSO is. In this use case, a user has a login session (that is, a security context) on a web site (Airplane.com) which maintains local identities for users and is accessing resources on that site. At some point he is directed over to a partner's web site (CarRent.com). We assume that a trust relationship has been previously established between Airplane.com and CarRent.com based on a business agreement between them.
The site (Airplane.com) asserts to the service provider site (CarRent.com) that the user is known, has authenticated to it. Since CarRent.com trusts Airplane.com, it trusts that the user is valid and properly authenticated and thus creates a local session for the user. The user is not required to re-authenticate when directed over to the CarRent.com site.
A
irplane.com
C
arRent.com Business agreement Authenticate
Access Protected
resource
12
Figure 2.2.1 General Single Sign-On Use Case