http://www.developer.com/services/article.php/1555791/Web-Services-Applications-and-Security-Part-2.htm

Back to article

Web Services Applications and Security: Part 2


December 11, 2002

What Are the Key Risk Factors in Web Services Application Development?

As Web Services move into complex business transactions, security will play a major role. Some of the services may only be available to paid users. So, protecting sensitive data is a critical factor for Web Services applications to succeed.

The key risk factor in this use case implementation is security. How can we make the Bookstore Application a secure application?

How can we protect credit card information that has passed to the Payment Service?

Let us go through the key requirements on Web Services security and different security scenarios, and examine the limitations and usage of each of them.

Web Services Security Key Requirements

The following requirements address the security of Web Services across distributed domains and platforms and provide security in a meaningful way.

  • The construction of a Web Services Model based on thorough analysis of existing and foreseeable threats to Web Services endpoints and their communication.
  • The construction of a Web Services Security Model that captures the security policies.
  • The realization of the security model in the form of a Web Services Security Framework that is an integral part of the Web Services Architecture.
  • The security framework must enable Authentication for the identities of communicating parties.
  • The security framework must enable Authorization.

Security Scenarios

Following are some of the scenarios that help you build a simple Web Services application that is secure and reliable. This article covers only the overview of each security scenario.

Note:
To apply/use these scenarios in your application development, you need to refer to/check how these methodologies are supported by your Application or Web Servers and read the documentation that is provided by the vendor for setup, configuration, and built-in support provided in the products.

When the Web Services Application is a concern, most security scenarios are mainly related to categories such as transport/network level security, data level security issues, and message level integrity.

Let us start with transport level security issues that are applicable to Web Service Application.

Figure 1—Data transfer over the networks

Scenario 1: Basic Authentication in a Web Service Application for a Request and Response to Messages

Description

Basic authentication is an authentication mechanism that allows users to access the service after verifying the user id and password granted for that user.

  1. In this approach, the server maintains the list of users and correspondence for users in a file.
  2. HTTP supports basic authentication, so when we try to access a resource from the server, the browser sends an Authentication Required header to the server.
  3. The server receives the request and responds back to the client with the response header.
  4. Once the client receives a response from the server, it will ask the user to pass a username and password to the server.
  5. The server verifies whether the username and password match the entries in the file or not. If they match, the server allows the client to access the resources.

Limitations/Issues:

  • HTTP is a stateless protocol; it does not maintain user information in a persistent way, so it asks the user to pass his user id and password for every new session with the server.
  • The password sent to the server over the network is not encrypted, so it can be hacked by anyone and misusd. Our next scenario will explain how we can overcome this issue.
  • For server-side implementation, it always looks in the text file for username and password verification. It is very slow when it needs to check a very large set of data. It ultimately affects the system's performance.

Technologies to be used:

Web Server, configuration files.

Scenario 2: Digest Authentication

It provides one level high to basic authentication mechanism. It solves some of the limitations of basic authentication. It is not completely different from basic authentication, but it takes care of password encryption to some extent. It generates a set of numbers based on the password and these numbers are hashed by the MD5 digest. It saves this password along with other items on the server side. This model provides secure transactions to some extent and the hackers cannot catch the password easily.

Limitations/Issues:

  • This model uses text files to store the authentication information. This is one of the limitations of the basic authentication model that applies here, also. The server takes a lot of time to verify the user name and password. An alternative mechanism is to use a database to store and retrieve usernames and passwords.
  • Although the password is not exchanged in a clear text format, there are chances that expert hackers may get get the password and could use a digested password to access the secure resources.

Scenario 3: Using Secure Socket Layer (SSL)

Description

SSL is a security protocol that provides more secure mechanism; it is built on top of the TCP/IP protocol suite. It is used to authenticate and encrypt data, and a client/server handshaking process to authenticate the data transfer between the processes.

It supports many algorithms, such as DSA (Digital Signature Algorithm), KEA (Key Exchange Algorithm), MD5 (Message Digest algorithm), RSA (A public-key algorithm), and so forth; they are used to authenticate data between client and server processes.

RSA is the most commonly used SSL encryption algorithm that uses the RSA key exchange. In this approach, server and client determine the symmetric keys they will both use during an SSL session.

For a simple Web Service application, we can use SSL as a secure channel to authenticate the transactions between the service provider and the service consumer. Using Soap over SSL is straightforward. We just need to enable SSL on the server side, in the same way that we would a standard Web application. After that, we have to install and configure SSL.

  • We need to create a certificate request, send it to a trusted Certificate Authority (CA), and install the certificate that the authority sends back.
  • Force SSL usage on Web Services by indicating the access point over HTTPS.
  • Client-side implementation is so simple; just install/use the client-side SSL API in the application.

Limitations

  • Current technologies for establishing secure connections over HTTP as the prevailing Web transport protocol—such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS)—may provide adequate security in some network settings, but do not meet all messaging security requirements in the Web Services framework.
  • SSL creates a tunnel between the two end points, so this is the major limitation to using SSL in a Web Services application that is using some SOAP Intermediaries.

Technologies to be used

SSL, JSSE

All the above scenarios mainly deal with transport level mechanisms to make the application secure. A Web Service application mainly uses XML as the core piece for data representation. So, securing data in an XML document is a major challenge to make a Web Service application secure. Part 3 of this series deals with how we can manage the XML data in a secure fashion.

About the Author

Sridhar Ravuthula is a senior software engineer with Hewlett-Packard, India. He has a master's degree in computer applications. Sridhar has been involved in designing and developing J2EE-based solutions on various platforms. He has worked in flagship product development, e-speak, and HP Bluestone (HPAS). He has good knowledge and hands-on experience in Web Services technologies. You can reach him at sridhar_ravuthula@hp.com or sridharravatula@yahoo.co.uk.

Sitemap | Contact Us