14.8 Use Scenario

14.9 Web Services Provider Security

In the previous section, we showed how loosely coupled applications can be integrated to provide a Web Services-based e-business solution. Users can invoke Web services using one of the supported protocols. For example, users can submit their SOAP requests over HTTP, and the requests are processed by the Web service engine. When Web services are used to provide business- related data, the data needs to be secured like any other data.

The Web application server that hosts the Web service engines can support various protocols. Sometimes, owing to the bundling of security with protocols, we need to begin to categorize the tasks to be performed as either transport-layer or message-layer security tasks and assign them to the appropriate handlers.

• A transport- protocol-specific handler can process protocol-specific information. In the case of HTTP, the handler might perform HTTP authentication and establish the context prior to the SOAP engine's getting a chance to process the message.

• A transport-protocol- agnostic handler can perform authorization based on authentication information, regardless of the transport. In the case of message-level security, the SOAP engine would handle the security tokens in the SOAP message, establish a security context, validate the signatures, and decrypt the message, as appropriate.

Once the user is authenticated, the Web service security provider should determine whether the invoking user has the authority to invoke the service. This authorization decision is based on the authorization policy associated with the Web service. In a J2EE environment, where the service is likely implemented as an enterprise bean, the authorization policy for the enterprise bean would be based on J2EE roles.

14.9.1 User Authentication

In order to secure access to a Web service, the user requesting the service needs to be identified through an underlying authentication mechanism, as shown in Figure 14.4.

An identity needs to be associated with a request in order to enforce authorization policies. A Web service security configuration should declare authentication policies that specify how to retrieve and verify the user credentials, or authentication data .

• In the J2EE security model, the login configuration policy specifies how a user's authentication data is retrieved (see Section 3.9.1 on page 77 and Section 4.5.1 on page 113), whereas policies specific to the operational environment will dictate how the user gets authenticated ”for example, using the Kerberos authentication mechanism.

• In the WS-Security model, the login configuration should address not only authentication of immediate clients ” clients submitting the request directly to the service ”but also the mode in which an end client's identity may be part of the request. (Requests can traverse through many intermediaries.) This information is necessary for both the client ”to submit the credential information in a format understood by the server ”and the server ”to retrieve the credential information from the transport layer or message itself.

The WSDL definition of the service may include security constraints on how the credential information is expected to be provided or retrieved. These constraints will be expressed by the runtime, using WS-Policy and the related specifications.

• An HTTP-bound service can expect data to be supplied through HTTP basic authentication.

• In the case of a Web service that can be accessed through an intermediary, the configuration should indicate that the credential information is expected as part of the message itself. For instance, the configuration can say that the authentication information is expected in the WS-Security message header, which is represented by the wsse:Security XML element in the SOAP header.

Based on these two possibilities, we can categorize that authentication data as supplied using transport-level security or message-level security, as when it is part of the WS-Security header.

Depending on the topology, a user may get authenticated by the Web service engine or up front before the Web service engine is handed the request. For example, when a user submits a request to the servlet that dispatches the Web service request, the user might be challenged by a front-end secure reverse proxy server, using the HTTP 401 challenge mechanism to prompt the user to submit a user ID and password pair.

In order to handle the authentication data that gets passed around through various means, a Web service engine can support both transport-level and message-level security.

• In a J2EE environment in which HTTP is the transport protocol used, the HTTP-specific handler, a servlet, can invoke the getUserPrincipal() method in the javax.servlet.http.HttpServletRequest interface to retrieve the identity of the user. If the user is not already authenticated as far as the underlying system is concerned , the container should authenticate the user, based on the credentials sent over the transport: for example, the user ID and password in the HTTP header.

• If the authentication credentials are sent over in the message itself, the SOAP engine will retrieve that authentication data and validate the assertion. In such cases, it may be possible to specify the authentication method as part of the Web service deployment descriptor. In other words, a Web service can be protected through mechanisms that are similar to expressing the login-config element in the web.xml deployment descriptor for a Web resource (see Section 3.9.1 on page 77 and Section 4.5.1 on page 113). Even though this option is not a J2EE standard yet, mechanisms specific to the Web service provider will be available to provide it. For example, IBM WebSphere ^[16] provides a mechanism whereby authentication, signature, and encryption requirements for protecting a Web service can be specified as part of a deployment descriptor that gets packaged with the Web service.

  ^[16] See http://www.ibm.com/websphere.

14.9.2 Authorization Enforcement

The authorization policies of a Web service can be enforced according to the authorization policies of the application environment. For example, when a Web service is implemented as an enterprise bean, the EJB authorization rules of the J2EE environment will apply.

In order for the Web service provider to enforce security constraints on Web services, the security policies need to be declaratively conveyed to the runtime authorization policy end point to ensure portability of the service from one WAS to another. Using this approach, the Web service provider infrastructure can take care of defining the security policies, and the Web service developers need not know how to programmatically enforce all possible authorization policies. This helps a service to be deployed in various servers, and the appropriate mechanism will be expected to enforce the policies.

As shown in Figure 14.5, user Bob, who is a registered Customer, is granted the permission to make travel reservations using TravelService. This security policy should be declared in the deployment descriptor of the service implementation ”in this case, TravelServiceBean, which is the enterprise bean providing the implementation behind the TravelService Web service. This is demonstrated by the deployment descriptor fragment in Listing 14.2.

Listing 14.2. Web Service Deployment Descriptor Fragment

<method-permission>

   <role-name>Customer</role-name>

   <method>

      <ejb-name>TravelServiceBean</ejb-name>

      <method-name>makeReservation</method-name>

   </method>

</method-permission>

In order for an authorization check to succeed, the user invoking the service should have at least one of the roles required to access the Web service. The mechanisms by which users and user groups are granted application roles are specific to the operational environment.

As the scenario of Figure 14.5 and the deployment descriptor fragment of Listing 14.2 show, the makeReservation() method on the TravelServiceBean implementation behind the TravelService Web service requires the role Customer. For example, if user Bob makes a request, his identity gets asserted in the WS-Security header. The security authorization handler will make the authorization decision, based on the asserted identity of the caller invoking the service. The ability to specify the authorization policy declaratively helps decouple the application security policy from organizational security policies while still effectively enforcing overall application security requirements.

Given that the authorization may be based on the service implementation, better protection is achieved by implementing the service as an enterprise bean and using the EJB role-based authorization facilities. If the service implementation is a Java bean, ^[17] the EJB role-based authorization does not apply. If SOAP is used in combination with HTTP (see Section 14.2 on page 499), one can protect the URL that leads to the SOAP engine processing the request. For example, in the TravelService scenario described earlier, if the service implementation is a Java bean and SOAP is used in combination with HTTP, one can protect the URL http://www.fabrikam456.com/travelServices. Note that this does not allow for operation-level, or method-level, protection. Also, if many services can be accessed through the same URI ( /travelServices ), they all will have the same protection characteristics.

^[17] See http://java.sun.com/products/javabeans/.

In conclusion, security should be considered not only after implementing a Web service but also before making the decision on how the Web service should be implemented. As technology evolves, it is possible that more fine-grained authorization can be applied, based on the SOAP message contents. At that point, the authorization mechanisms built around the Web service implementation can be combined with those based on the SOAP message contents.