Applying security to webservice message layer on glassfish In this entry,  I am going to provide the basic information on "how one can use the webservices security using Glassfish/ Sun Java System Application Server" where webservices' soap messages can be protected without changing the webservices implementation or invocation code. 

When the webservice client send the soap messages to the webservice endpoint, these soap messages are in clear text. In order to protect your messages from source (client) to destination (endpoint), AppServer providers the message layer security for webservices (uses WS-Security spec defined by OASIS) by injecting <wsse:Security> elements based on the configured policy mechanisms. Glassfish appserver by default configurs the required providers and users can enable and/or change the required policies. The default policy configured in the appserver is Signing (<wsse:BinarySecurityToken> ..<ds:Signature..>).

How to use the default message protection [using default configured policy (Signature) ]-

Here are the basic steps one can use and refer the appserver administration guide for more details on the commands and additional functionality.

1. Enable the server side providers
    Using Admin console-> http://localhost: <adminport>/ 
                         Go to (left frame. click on the nodes) ->Configuration->Security->Message Security-->SOAP
                         Select (right frame) Default Provider ->"Server Provider" from the dropdown list
                                    Default Client Provider ->"Client Provider" from the dropdown list
                          Click "Save" button  (notice that values saved and Restart Required warning)

    Using asadmin  CLI command [    Note that passfile contain "AS_ADMIN_PASSWORD=<password>"] :

2. Restart the server
   i) Stop domain
    <appserver>/bin/asadadmin stop-domain  <domain-name>
    Ex. /export/munta/as9/bin/asadadmin stop-domain  domain1
   ii) Start  domain
    <appserver>/bin/asadadmin start-domain  <domain-name>
    Ex. /export/munta/as9/bin/asadadmin start-domain  domain1
  
At this point all deployed or future deployed webservices are protected at message layer with Signing policy. Your client should match with the same policy as in the server and is by default no changes required.

3. Enable the clide side provider

    Edit client container configuration file,  <admin.domain.dir>/<admin.domain>/sun-acc.xml   to add a client provider to the soap layer that matched the provider-id.
    Ex. /export/munta/as9/domains/domain1/config/sun-acc.xml   --> add the highlighted provider

<!DOCTYPE client-container ....
<client-container>
  <target-server name="munta" address="munta" port="53700"/>
  <log-service file="" level="WARNING"/>
  <message-security-config auth-layer="SOAP" default-client-provider="ClientProvider">
        <!-- turned off by default -->
        <provider-config class-name="com.sun.xml.wss.provider.ClientSecurityAuthModule" provider-id="ClientProvider" provider-type="client">
        <request-policy auth-source="content"/>
         <response-policy auth-source="content"/>
         <property name="security.config" value="/export/munta/as9pe/lib/appclient/wss-client-config-2.0.xml"/>
 </provider-config>
 </message-security-config>
</client-container>



4. Access the webservice appclient with following  default keyStore and trustStore properties (using Signing or binary token)  and point the -xml to the above xml path (by default it is point to  domain1/config/sun-acc.xml)

     Set the following environment  variable before access the appclient:

   VMARGS ="-Djavax.net.ssl.keyStore=<admin.domain.dir>/<admin.domain>/config/keystore.jks -Djavax.net.ssl.trustStore=<admin.domain.dir>/<admin.domain>/config/cacerts.jks"
  Ex. setenv VMARGS  "-Djavax.net.ssl.keyStore=/export/munta/as9/domains/domain1/config/keystore.jks -Djavax.net.ssl.trustStore=/export/munta/as9/domains/domain1/config/cacerts.jks"


*Your client will be  running normally but messages are protected!

How do I know webservice messages are protected?

You can see the SOAP messages dump in the client console by doing the following 2 steps:
1) Edit client container configuration file, sun-acc.xml   to have the INFO level log.

        <log-service file="" level="INFO"/>

2)  Edit client side wss security configuration file  (don't edit any other elements in the file as this configuration file is mainly used by the server and transparant to the user!)
      at <appserver>/lib/appclient/wss-client-config-2.0.xml  to the following highlighted.
Example. /export/munta/as9pe/lib/appclient/wss-client-config-2.0.xml

<xwss:SecurityConfiguration xmlns:xwss="http://java.sun.com/xml/ns/xwss/config"
                            dumpMessages="true">

Now you can re-run the webservice client again and see that SOAP messages are dumped on to the client console with new security elements (<wsse:)

Example [ note: removed the content (filled with .....)  to reduce the space]:

 Feb 3, 2006 7:26:11 PM com.sun.xml.wss.impl.filter.DumpFilter process
 INFO: ==== Sending Message Start ====
 <?xml version="1.0" encoding="UTF-8"?>
 <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <env:Header>
 <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
 <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-11390235703121194903842">MIIClDCCAf0CBEPkDe4wDQYJKoZIhvcNAQEEBQAwgZAxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpD
 .......
 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 .......
 </wsse:Security>
 </env:Header>
 <env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1139023571163-313201494">
 .......
 </env:Body>
 </env:Envelope>
 ==== Sending Message End ====

 Feb 3, 2006 7:26:12 PM com.sun.xml.wss.impl.filter.DumpFilter process
 INFO: ==== Received Message Start ====
 <?xml version="1.0" encoding="UTF-8"?>
 <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns0="http://tax.org/wsdl" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <env:Header>
 <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" env:mustUnderstand="1">
 <wsse:BinarySecurityToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary" ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" wsu:Id="XWSSGID-1139023367140-550544941">MIIClDCCAf0CBEPkDe4wDQYJKoZIhvcNAQEEBQAwgZAxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpD
 .......
 <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 .......
 </wsse:Security>
 </env:Header>
 <env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1139023571907-1675963724">
 .......
 </env:Body>
 </env:Envelope>

 ==== Received Message End ====

Posted by Jagadesh Babu Munta ( Feb 03 2006, 07:56:20 PM PST ) Permalink Comments [4]