Troubleshooting JAXWS Message Level Security in GlassFish

In Java EE 5, one can implement JAXWS Web Services through servlets and Ejb endpoints (JSR 109). GlassFish supports message level security for Web Services. You don't need to write special client and server Java code in order to take advantages of the message level security. What you need to do is specific a corresponding message-level-security element in sun-ejb-jar.xml, sun-web.xml, and sun-application.xml. For instance,

  <webservice-endpoint>
    <port-component-name>PingEjb</port-component-name>
    <endpoint-address-uri>/PingEjbService/PingEjb</endpoint-address-uri>
    <message-security-binding auth-layer="SOAP" provider-id="XWS_ServerProvider">
      <message-security>
        <message/>
        <request-protection auth-source="sender"/>
        <response-protection auth-source="content"/>
      </message-security>
    </message-security-binding>
  </webservice-endpoint>

Or you can turn on the default in domain.xml for server side or sun-acc.xml for appclient.

This blog will highlight some troubleshootings for JAXWS message level security.

Read logs

  1. Look at client and server logs. The server log is located at $GLASSFISH_HOME/domains/your_domain/logs/server.log.
  2. If you want to see more SOAP level debug info, like corresponding SOAP messages, then you can turn on provider's debug.
    For server and embedded client, one can achieve this by navigating from admin console: Configuration > Security > Message Security > SOAP > Providers:
    • For server, choose the provider XWS_ServerProvider, change the debug property to true and save the configuration.
    • For embedded client, choose the provider XWS_ClientProvider, change the debug property to true and save the configuration.
    For appclient, one need to change the debug property to true for the provider XWS_ClientProvider, and log-service level to INFO.

Endpoint info mismatch

For message level security, one need to ensure that the same request-policy and response-policy are applied to both client and server. These info can be specified in sun-\*.xml for a given application or domain.xml and sun-acc.xml for default provider configuration (if default is on). If you see com.sun.xml.wss.impl.PolicyViolationException: Expected Signature Element as per receiver requirements or there is no security processing in SOAP message in debug log, then most probably some of the info about endpoint in sun-\*.xml is not correct. You may like to double check each port-component-name (defined in JSR 109) and endpoint-address-uri inside message-security-binding in sun-\*.xml are correct.

Note:

  • According to JSR 181, we have the following:
    ValueDefault
    @WebService.nameSimple name of the Java class or interface
    @WebService.serviceNameSimple name of the Java class + "Service"

  • In GlassFish, the URL to access WebService and endpoint-address-uri in sun-\*.xml are related as follows:
    Endpoint TypeWebService URL
    Servlethttp[s]://host:port/context-root/endpoint-address-uri
    Ejbhttp[s]://host:port/endpoint-address-uri

  • One can also find out the port-component-name by checking the generated webservices.xml in admin console as follows: Web Services > YOUR_WEB_SERVICES > Webservices.xml, and then correct the port-component-name, repackage and redeploy your application if necessary.
Comments:

I've been trying to get this work by using sun-web.xml configuration with no luck.

Log file says that no such port-component was found. I also can't find webservices.xml and the Web Services listing in admin site empty.

My web service has sun-jaxws.xml, web.xml (service configured as servlet using WSServlet) and sun-web.xml.

Packaged and deployed as WAR, it never gets listed in Web Services listing although it is working fine.

I'm using Sun Application Server 9.0 and Glassfish.

Posted by John C. on December 07, 2007 at 06:39 PM PST #

In case other people are having John C's problem:

You need to follow JSR 109 to develop the JAXWS webservice. What this means is that you should NOT have a web.xml in your deployed war file. If you have a web.xml that refers to WSServlet, then Glassfish treats it as a normal servlet and not as a web service.

I wish the Metro and Glassfish documentation were clearer about this since I now have lots of webservices with a web.xml that I now need to go and remove. Sigh!

Posted by Lak on October 22, 2008 at 01:18 PM PDT #

I am using netbeans 6.5 and glassfisn v2u2/sun application server
for a simple secure web service. I have configured message level
security through Sun Application console and modified the config files
based on the information in this blog, but still got the
following error in Sun App server log (see below), Could you please
advise what may wrong?

[#|2008-11-21T15:17:12.137-0600|WARNING|sun-appserver9.1|javax.enterprise.system
.stream.err|_ThreadID=14;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=4c84e
3b2-b110-42f9-90e5-b6f6ed0e78be;|\^M
com.sun.xml.wss.XWSSecurityException: com.sun.xml.wss.impl.PolicyViolationExcept
ion: Expected Signature Element as per receiver requirements, found EncryptedKey\^M
at com.sun.xml.wss.impl.SecurityRecipient.processMessagePolicy(SecurityR
ecipient.java:858)\^M
at com.sun.xml.wss.impl.SecurityRecipient.processMessagePolicy(SecurityR

Posted by Don Zhang on November 21, 2008 at 05:40 AM PST #

To get rid of the error message posted in my previous message, I turn
off the message level security at the Sun Application server, and just added binding in sun_web.xml file. The WS WSDL also has the binding done through netbean IDE. It seems that the server/web service recognizs
the incoming request as signed/encrypted, but got the following error
in processing the incoming web service request:

[#|2008-11-21T16:40:31.692-0600|SEVERE|sun-appserver9.1|javax.enterprise.system.
core.security|_ThreadID=15;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=e5f
4cb0a-8019-4206-b5f7-31a16696d2ec;|SEC2002: Container-auth: wss: Error validatin
g request \^M
java.lang.NullPointerException\^M
at com.sun.xml.ws.security.opt.impl.incoming.processor.SignedInfoProcess
or.processReferences(SignedInfoProcessor.java:358)\^M
at com.sun.xml.ws.security.opt.impl.incoming.processor.SignedInfoProcess
or.process(SignedInfoProcessor.java:183)\^M
at com.sun.xml.ws.security.opt.impl.incoming.Signature.process(Signature
.java:203)\^M

Please help as I have been struggling with this for two weeks now and go nowhere.

Thanks
Don

Posted by Don Zhang on November 21, 2008 at 06:48 AM PST #

Here is my section I manually added to my sun-web.xml webservice.xml files:

<message-security-binding auth-layer="SOAP" provider-id="XWS_ServerProvider">
<message-security>
<message>
<java-method>
<method-name>sendStatus</method-name>
</java-method>
</message>
<request-protection auth-source="content"/>
<response-protection auth-source="content"/>
</message-security>
</message-security-binding>

Posted by guest on November 21, 2008 at 06:54 AM PST #

Hi. We have a custom Jaspi SAM for a propietary SSO system running on Glassfish v2. The httpservlet version works fine, but the server don't call the soap version.

This is the end point configuration (sun-web.xml):

<servlet>
<servlet-name>JaspiCarWebService</servlet-name>
<webservice-endpoint>
<port-component-name>JaspiCarWebService</port-component-name>
<endpoint-address-uri>JaspiCarWebServiceService</endpoint-address-uri>
<message-security-binding auth-layer="SOAP" provider-id="SoapCarSam">
<message-security>
<message>
<java-method>
<method-name>\*</method-name>
</java-method>
</message>
<request-protection auth-source="sender"/>
<response-protection auth-source="content"/>
</message-security>
</message-security-binding>
</webservice-endpoint>
</servlet>

Posted by Fernando on November 24, 2008 at 09:20 PM PST #

Post a Comment:
Comments are closed for this entry.
About

Shing Wai Chan

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today