< Day Day Up > |
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.
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 AuthenticationIn 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 expressed by the runtime, using WS-Policy and the related specifications.
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 EnforcementThe 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> 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, [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.
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. |
< Day Day Up > |