Java Web Service: Fine-grained use of ws-security

In a simple WEB service environment, the client connects directly to the server, and the server performs all the necessary processing directly on the request. As described in the previous article in this series, connections that provide protection with SSL can provide excellent security for most applications in such environments. However, more complex environments are becoming more common, involving the use of multi-tier servers to process requests. The complete concept of service orchestration, which is increasingly popular in many enterprise environments, is based on this approach, as is the concept of service-oriented architecture (SOA). In these types of environments, more powerful ws-security alternatives must be implemented.

As mentioned in the previous installment, Ws-security has brought heavy performance costs. One way to reduce costs is to set the appropriate ws-securitypolicy for each operation defined by the service, or even the message, rather than applying a single ws-security policy to the entire service. Ws-security's fine-grained use requires more content than a rigid approach, but if applied correctly, it can reduce the performance overhead of common operations without weakening the security of operations that require ws-security.

Defining policies

The sample policies used in this article are the same as those in "Axis2 ws-security Foundation" and "Axis2 ws-security signature and Encryption"-a simple library management service. This service defines three kinds of actions:

GetBook, retrieves the details of a particular book identified by International Standard Books number (ISBN).

Getbooksbytype, retrieves the details of all books of a certain type.

Addbook, add a new book to the library.

To add some interesting changes to the security use case, this article makes the following assumptions:

The GetBook operation can be safely exposed to anyone (security is not applied).

Getbooksbytype requires authorization (and therefore uses UsernameToken).

The Addbook operation requires an audit trail to track who added the book (by signing the request message).

In earlier articles, you've learned how to configure Axis2/rampart: Connect a ws-securitypolicy document to a Org.apache.axis2.client.ServiceClient instance (on the client side). Or embed the policy document into the Services.xml service configuration (on the server side). This method works and can be used for testing, but for production applications it is best to relate ws-securitypolicy directly to the service definition by embedding it in a WSDL document. Ws-policy and Ws-securitypolicy are designed to provide support for this embedding and to use from <wsdl:binding>, <wsdl:binding>/<wsdl:operation> or The reference identity of the <wsdl:binding>/<wsdl:operation>/<wsdl:message> definition will be applied to the appropriate policy for the binding, action, or message. The Axis2 1.4.1 implements the initial processing of the policies that are embedded in the WSDL, and this implementation is improved in the current AXIS2 1.5 release code. To demonstrate the use of the strategy in WSDL, this article uses the AXIS2 1.5 release code and the latest Rampart code that has not yet been released (the latter will eventually be released as Rampart 1.5).

Listing 1 shows the WSDL for the sample application, where the policy is added and referenced in the appropriate location. (Listing 1 is edited for length and width; the full WSDL can be obtained from the library.wsdl file in the code download). Each policy defines an ID value that is subsequently referenced from the appropriate action (for the UsernameToken policy) or message (for the signing policy), showing all policies in bold.

Listing 1. WSDL with fine-grained security policy <wsdl:definitions targetnamespace= "HTTP://WS.SOSNOSKI.COM/LIBRARY/WSDL"


xmlns:wns= "HTTP://WS.SOSNOSKI.COM/LIBRARY/WSDL"


xmlns:tns= "Http://ws.sosnoski.com/library/types"


xmlns:wsdl= "http://schemas.xmlsoap.org/wsdl/"


xmlns:wsdlsoap= "http://schemas.xmlsoap.org/wsdl/soap/" >





<!--Policy for signing message, with certificate from client included in each


message to server-->


<wsp:policy wsu:id= "signonly" xmlns:wsu=


"Http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"


xmlns:wsp= "Http://schemas.xmlsoap.org/ws/2004/09/policy" >


<wsp:ExactlyOne>


<wsp:All>


<sp:asymmetricbinding


xmlns:sp= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" >


<wsp:Policy>


<sp:InitiatorToken>


<wsp:Policy>


<sp:x509token sp:includetoken= ".../includetoken/alwaystorecipient"/>


</wsp:Policy>


</sp:InitiatorToken>


　　　　　　 ...


</wsp:Policy>


</sp:AsymmetricBinding>


<sp:signedparts


xmlns:sp= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" >


<sp:Body/>


</sp:SignedParts>





</wsp:All>


</wsp:ExactlyOne>


</wsp:Policy>





<!--Policy for UsernameToken with plaintext password, sent from client to


Server only-->


<wsp:policy wsu:id= "UsernameToken" xmlns:wsu=


"Http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"


xmlns:wsp= "Http://schemas.xmlsoap.org/ws/2004/09/policy" >


<wsp:ExactlyOne>


<wsp:All>


<sp:supportingtokens


xmlns:sp= "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" >


<wsp:Policy>


<sp:usernametoken sp:includetoken= ".../includetoken/alwaystorecipient"/>


</wsp:Policy>


</sp:SupportingTokens>


</wsp:All>


</wsp:ExactlyOne>


</wsp:Policy>


　 ...


<wsdl:binding name= "librarysoapbinding" type= "Wns:library" >





<wsdlsoap:binding style= "Document"


transport= "Http://schemas.xmlsoap.org/soap/http"/>


<wsdl:operation name= "GetBook" >


<wsdlsoap:operation soapaction= "Urn:getbook"/>


<wsdl:input name= "Getbookrequest" >


<wsdlsoap:body use= "literal"/>


</wsdl:input>


<wsdl:output name= "Getbookresponse" >


<wsdlsoap:body use= "literal"/>


</wsdl:output>


</wsdl:operation>





<wsdl:operation name= "Getbooksbytype" >


<wsp:policyreference


xmlns:wsp= "Http://schemas.xmlsoap.org/ws/2004/09/policy"


uri= "#UsernameToken"/>


<wsdlsoap:operation soapaction= "Urn:getbooksbytype"/>


<wsdl:input name= "Getbooksbytyperequest" >


<wsdlsoap:body use= "literal"/>


</wsdl:input>


<wsdl:output name= "Getbooksbytyperesponse" >


<wsdlsoap:body use= "literal"/>


</wsdl:output>


</wsdl:operation>





<wsdl:operation name= "Addbook" >


<wsdlsoap:operation soapaction= "Urn:addbook"/>


<wsdl:input name= "Addbookrequest" >


<wsp:policyreference


xmlns:wsp= "Http://schemas.xmlsoap.org/ws/2004/09/policy"


uri= "#SignOnly"/>


<wsdlsoap:body use= "literal"/>


</wsdl:input>


<wsdl:output name= "Addbookresponse" >


<wsdlsoap:body use= "literal"/>


</wsdl:output>


</wsdl:operation>





</wsdl:binding>


<wsdl:service name= "Library-granular" >


　　 ...


</wsdl:service>


</wsdl:definitions>

The policies and WSDL in Listing 1 are from earlier articles, but are not merged in advance in this article. However, you will find a significant difference in the strategy: Earlier versions included Rampart configuration information that was specific to the client or server. Now that the policy is embedded in the WSDL, it is not appropriate to include the Rampart configuration directly. (You need to edit the WSDL to contain the client Rampart configuration information and regenerate the code each time a change occurs, and on the server side, the Rampart configuration will be exposed to anyone accessing the WSDL). So the sample code sets the configuration information separately. To do this, the included Rampart configuration uses different variants of the same techniques that were previously used for the policy.