7.1. Security Scenarios
Enterprise environments with Web site applications have a variety of security use case scenarios. Although the spread of Web services has given rise to additional security use cases, these Web services application use cases have similar security needs to those of Web-based enterprise applications (such as browser-based applications accessing Web sites). Typically, Web site and Web service application use cases involve access to services through the Internet or an intranet, allow users to access certain sets of resources but not others, and allow users to perform some set of actions. In addition, users might require access to other resources, such as a database, and they might need to interact with other applications.
Some of the security needs of Web site applications and Web services are very similar. For example, a Web site application must authenticate its users, and a Web service application must authenticate its clients. However, Web services applications have additional security needs, because their use cases are typically application to application rather than user to application and because their communication interaction uses new technologies. Later in this chapter we examine security issues specific to Web services, plus we look at the specific details for implementing Web services-specific security mechanisms.
Let's first look at some typical Web services scenarios and examine the secure interactions between clients and services. Not only do we look at security issues relevant to client and service interactions, we also examine how service endpoints interact in a secure manner with resources and components of an enterprise to process requests. Before doing so, however, we examine basic security requirements.
7.1.1. General Security Requirements
Although varying greatly in implementation and functionality, J2EE Web services scenarios have common security requirements. They require certain security constraints for message exchange interactions and data passing between a client and a service. In addition to securing service and client interactions, Web service endpoints must be able to securely access other J2EE components (such as entity beans) and external resources (such as databases and enterprise information systems) to process client requests. While processing a client request, service endpoints may also need to interact with other Web services, and this, too, must be done in a secure manner.
Figure 7.1 shows a Web service interaction in which a client request to the service causes the service endpoint to interact with other components, resources, and systems. It illustrates that a Web service request can take many paths and result in interactions with different containers, components, and resources, including other Web services. Requests to a Web service start with a client sending a message to a Web service endpoint running in a Web or EJB container.
However, designing a secure Web service involves more than just securing the initial interaction between the client and the service. For a truly secure service, you must also consider the security needs of the Web service endpoint's subsequent interactions with other J2EE components, resources, and so forth, that it undertakes to process the request.
Most client requests to a service require the service to access a series of components to fulfill the request and each call might have its own, unique security requirement. This results in a chain of calls to various components, some of which might be within the initiating component's security domain and others of which are outside that security domain. With such a chain of component calls, each cooperating component in the chain must be able to negotiate its security requirements. In addition, components along the chain might use different security protocols. In short, security needs to flow from a client to a called component, then to other components and resources, while passing through different security policy domains.
A J2EE application must be able to integrate its own security requirements and mechanisms with those of different components and systems. For example, a client might make a request to a Web service. The client call is to an endpoint, which in turn might call other Web services, make IIOP calls, access resources, and access local components. Each component—other Web services, local and remote components, and resources—has its own security requirements. If it interacts with an EIS system, a Web service endpoint must be able to handle the security requirements and mechanisms that the EIS system requires for authentication and authorization.
Some of the common security requirements for a Web service are authentication, access control, establishing a secure channel for exchanging messages, message-level security, and securing the interaction with other components when processing requests. Let's examine how these security requirements express themselves with Web services.
7.1.1.1. Authentication
Authentication, or proving one's identity, is often required by both a Web service and a client for an interaction to occur. A Web service might require that clients provide some credentials—such as a username and password, or a digital certificate such as an X.509 certificate—to help in proving their identity. The client of a Web service might require that a service provide it with some evidence to help establish its identity, which typically is done using a digital certificate.
Furthermore, since a Web service might need to access other components and resources to process a client's request, there are authentication requirements between a service and resources that it uses. The service might need to provide identity information to authenticate itself to resources and components. The resources and components might also have to prove their identity to the service. The same authentication requirements hold true between Web services if the service endpoint needs to access other Web services.
Thus, authentication occurs across different layers and different types of systems and domains. Passing identity along the chain may also require that the identity change or be mapped to another principal.
7.1.1.2. Access Control
Controlling access to a service is as important as authentication. A service endpoint might want to let only certain authorized clients access its services. Or, an application might want to restrict different sets of its resources and functionality to different groups of clients. An endpoint might allow all clients to invoke its basic service, but it might grant some clients extra privileges and access to special functions. For example, you might want to limit access to only users who are classified as managers or to only users who work for a particular department. In short, all clients are not equal in terms of their permissions to access or use services or resources.
Because a service endpoint also needs to interact with other components and resources, the endpoint needs some way to control access to them. That is, the endpoint needs to be able to specify resources that have restricted access, to group clients into logical roles and map those roles to an established identity, and, while processing a service request, to decide whether clients with a particular identity can access a particular resource.
7.1.1.3. Secure Channel for Message Exchange
A client's utilization of a Web service entails numerous message exchanges, and such messages may contain documents, input parameters, return values, and so forth. Since not all messages require security, an application needs to identify those messages requiring security and ensure that they are properly protected.
Some message exchanges, such as passing credit card information, require confidentiality. For these messages, the interaction between a client and a Web service must be encrypted so that unintended parties, even if they manage to intercept the message, cannot read the data.
Interactions between a client and a Web service might require integrity constraints. That is, message exchanges between a client and a service might require a digital signature to verify that the message was not altered in transit. The message recipient, by validating a signature bound to a message, verifies the integrity of the message.
To handle interactions requiring integrity and confidentiality, it is important to establish secure channels for exchanging messages. Applications use HTTPS and digital certificates to establish such secure channels. HTTPS provides a secure message exchange for one hop between two parties.
7.1.1.4. Message-Level Security
Besides creating a secure communication channel between a client and a Web service, some Web service message exchanges might require that security information be embedded within the SOAP message itself. This is often the case when a message needs to be processed by several intermediary nodes before it reaches the target service or when a message must be passed among several services to be processed.
Message-level security can be useful in XML document-centric applications, since different sections of the XML document may have different security requirements or be intended for different users.
7.1.2. Security Implications of the Operational Environment
The operational environment within which Web services interactions occur is an important factor in your security design. Service interactions occurring entirely within an enterprise have very different security requirements than service interactions open to everyone on the Internet. Thus, the relationship among Web service participants—such as Internet, intranet, and extranet—is an important consideration. When participants are closely aligned, you have a greater ability to negotiate security requirements.
In essence, the more control you have over the environment in which the Web service participants run, the easier it is to solve your security design. For example, if the Web services limit communication to applications inside your enterprise, then the network's physical security might shield the Web service. The operational environment security might be sufficient to satisfy your security needs. Similarly, Web services in environments that require communication via a Virtual Private Network (VPN) might not need to worry about issues such as confidentiality, since the communication channel is already secure.
When all participants are trusted, such as within one enterprise, it is an easier matter to set up and exchange security keys. However, this is a difficult challenge for untrusted participants with an open Internet Web service.