|< Day Day Up >|
14.8 Use Scenario
Let us take a very simple scenario whereby a travel agency system contacts an airlines reservation system in order to complete a travel transaction request. The two applications ”the Travel Agency Web service and the Airlines Web service, respectively ”use XML to exchange travel
The Fabrikam456 Travel Agency Company's application is designed to accept a reservation request with a
tag from a customer. Based on the airline details
A user surfs for the best-possible travel deal and decides to purchase the ticket from the Fabrikam456 Travel Agency Company. The
When the travel agency receives the message from the airline, the application
The Web service that provides the reservation service in a service network can be combined with other Web services, such as a weather Web service to obtain the weather forecast for the travel destination, and a credit Web service to charge the end user for the travel expense. This way, Fabrikam456 Travel Agency Company can automatically issue tickets and schedule ticket delivery with shipping companies through the Fabrikam456 Web service.
This example describes a simple Web service in which two or more functions cooperate through the Web, and the nature of their cooperation adapts to parameters provided by a particular request. As you can see, Web Services technology provides a framework for
|< Day Day Up >|
|< Day Day Up >|
14.9 Web Services Provider Security
In the previous section, we showed how loosely
The Web application server that
Once the user is authenticated, the Web service security provider should determine whether the invoking
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.
Figure 14.4. Web Services Authentication
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 .
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
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.
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
As shown in Figure 14.5, user Bob, who is a registered Customer, is granted the permission to make travel
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>
Figure 14.5. Authorization Scenario
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,  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.
In conclusion, security should be
|< Day Day Up >|