Chapter 6. Web Services Security

Security for web services covers a lot of territory, which cannot be explored all at once. To make the exploration more manageable, it seems best to analyze small chunks, one at a time, before pulling the exploration results together. Here is a sketch of how this chapter breaks up the broad topic of security into smaller pieces:

Wire-level security

Security begins at the transport or wire level with basic protocols that govern communications between a web service, whether SOAP-based or REST-style, and its clients. Security at this level typically provides three services. First, the client and service need transport-level assurance that each is communicating with the other rather than with some impostor. Second, the data sent from one side to the other need to be encrypted strongly enough so that an interceptor cannot decrypt the data and thus gain access to the confidential information carried therein. Third, each side needs assurance that the received message is the same as the sent message. This chapter covers the basics of wire-level security with code examples, most of which focus on HTTPS as a provider of wire-level security.

User authentication and authorization

Web services provide clients with access to resources. If a resource is secured, then a client needs the appropriate credentials to gain access. The credentials are presented and verified through a process that usually has two phases. In the first phase, a client (user) presents information such as a username together with a credential such as a password. If the credential is not accepted, access to the requested resource is denied. The first phase is known as user authentication. The second phase, which is optional, consists of fine-tuning the authenticated subject’s access rights. For example, a stock-picking web service might provide all paying customers with a username and password, but the service might divide the customers into categories such as regular and premier. Access to certain resources might be restricted to premier clients. The second phase is known as role authorization. This chapter introduces users/roles security, a common name for the two-phase process.

WS-Security

WS-Security, or WSS for short, is a collection of protocols that specify how different levels of security can be enforced within the SOAP-messaging infrastructure rather than through a particular transport (for instance, HTTPS) or through a particular service container (for instance, Tomcat). For example, WSS specifies how digital signatures and encryption information can be inserted into SOAP headers. If SOAP-based services are to be transport-neutral, then various security features must be built into SOAP itself. Accordingly, WSS is meant to provide comprehensive end-to-end security regardless of the underlying transport and the container that hosts the service. This chapter introduces WS-Security with an example.