X

Technology insights, news and tips.

  • Sun
    March 16, 2007

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 providerXWS_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 andendpoint-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.

Join the discussion

Comments ( 6 )
  • John C. Saturday, December 8, 2007

    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.


  • Lak Wednesday, October 22, 2008

    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!


  • Don Zhang Friday, November 21, 2008

    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


  • Don Zhang Friday, November 21, 2008

    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


  • guest Friday, November 21, 2008

    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>


  • Fernando Tuesday, November 25, 2008

    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>


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.