Specify WS-Security Handler using JEE standards

[vdurbha]

I'm using JBoss 5.0.0 GA and the native web services stack to create and deploy web services. I use JBoss specific annotation in my endpoint as follows:

@EndpointConfig(configName="Standard WSSecurity Endpoint")

Is it possible to avoid using this JBoss specific annotation and use JEE standard annotation @HandlerChain and specify the handlers?

Also when I'm creating a standalone web service client, I had to include this line in my client to make it work.

((StubExt)port).setConfigName("Standard WSSecurity Client");

Is it possible to avoid this and set handlers through code using into the BindingProvider?

When I tried to do both the above, I wasn't able to get the web service working? If anyone can share their experiences doing this, it would be of great help.

[vdurbha]

After trying various options, I finally figured out a way to write a completely generic client by removing the StubExt dependency. This was achieved by using the @HandlerChain annotation on the Service class. This may also work if we use the annotation on the SEI. And then I defined the handler in an xml and referred to it in the annotation as follows:

@HandlerChain(file="HelloWorldHandlerChain.xml")

But the server side endpoint still does not work if I use @HandlerChain annotation instead of @EndpointConfig to set the security handler. After digging into the source code of JBossWS and the log files for a few hours, I understood that for the WS-Security handler to work correctly, it has to be configured as a POST Handler type. When I used @HandlerChain annotation, it is configured as ENDPOINT Handler type. I was not able to find anyway to specify the type of handler in a standard way.

So for now, I'm guessing there is no escape from the @EndpointConfig proprietary annotation. Can someone please confirm the same? I would love to hear that I"m wrong with this because it is not a good idea to fill the source code with proprietary stuff. Doing this in a JBoss specific configuration file will be more cleaner as the code can then easily migrated to a different server without changes to source code.

[asoldano]

"vdurbha" wrote:
But the server side endpoint still does not work if I use @HandlerChain annotation instead of @EndpointConfig to set the security handler. After digging into the source code of JBossWS and the log files for a few hours, I understood that for the WS-Security handler to work correctly, it has to be configured as a POST Handler type. When I used @HandlerChain annotation, it is configured as ENDPOINT Handler type. I was not able to find anyway to specify the type of handler in a standard way.

You're right, you can't configure POST handlers using the standard descriptor.
This is a limitation of the native stack; in the case of ws-addresing configuration you can use the standard @Addressing annotation, but there's no similar standard annotation for ws-security. Do you have multiple handlers? Never tried, but I though ws-security native impl could work even with ENDPOINT handlers if they're in the right position in the chain and there aren't other handlers in POST (decryption needs to happen first, encryption needs to happen last)

[ivlcic]

I've been looking for the same sollution and found this workaround:

I replaced standard client conf with secure one so everything in your app will be under WS-Security. (If you dont need everything encrypted use the wiki instructions)

Write your own "endpoint-config" and place it in war
META-INF/standard-jaxws-endpoint-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jaxws-config:2.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:javaee="http://java.sun.com/xml/ns/javaee"
 xsi:schemaLocation="urn:jboss:jaxws-config:2.0 jaxws-config_2_0.xsd">

<endpoint-config>
 <config-name>Standard Endpoint</config-name>
 <post-handler-chains>
 <javaee:handler-chain>
 <javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings>
 <javaee:handler>
 <javaee:handler-name>WSSecurity Handler</javaee:handler-name>
 <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerServer</javaee:handler-class>
 </javaee:handler>
 <javaee:handler>
 <javaee:handler-name>Recording Handler</javaee:handler-name>
 <javaee:handler-class>org.jboss.wsf.framework.invocation.RecordingServerHandler</javaee:handler-class>
 </javaee:handler>
 <javaee:handler>
 <!-- YOUR OWN HANDLERS IN POST CHAIN -->
 <javaee:handler-name>Encrypted Request Logger</javaee:handler-name>
 <javaee:handler-class>org.dropchop.mpg.ws.RequestLogger</javaee:handler-class>
 </javaee:handler>
 </javaee:handler-chain>
 </post-handler-chains>
</endpoint-config>

</jaxws-config>

and client side .jar (or just in class path) META-INF/standard-jaxws-client-config.xml:

<?xml version="1.0" encoding="UTF-8"?>
<jaxws-config xmlns="urn:jboss:jaxws-config:2.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:javaee="http://java.sun.com/xml/ns/javaee"
 xsi:schemaLocation="urn:jboss:jaxws-config:2.0 jaxws-config_2_0.xsd">

<client-config>
 <config-name>Standard Client</config-name>
 <post-handler-chains>
 <javaee:handler-chain>
 <javaee:protocol-bindings>##SOAP11_HTTP ##SOAP11_HTTP_MTOM</javaee:protocol-bindings>
 <javaee:handler>
 <javaee:handler-name>WSSecurityHandlerOutbound</javaee:handler-name>
 <javaee:handler-class>org.jboss.ws.extensions.security.jaxws.WSSecurityHandlerClient</javaee:handler-class>
 </javaee:handler>
 </javaee:handler-chain>
 </post-handler-chains>
 <property>
 <property-name>http://org.jboss.ws/http#chunksize</property-name>
 <property-value>2048</property-value>
 </property>
</client-config>
</jaxws-config>

Your files will be loaded before the ones from jboss libs and you can delete all references to jboss libs from your source code.

I guess its a hack, but in my humble opinion after reading a spec (JAX-WS 2.1), user of native stack should be able to add his(hers) processing logic before SOAP protocol handling. With current jbossws (in AS 5.0.0GA) this is imposible since POST chains are delgated to execution before ENDPOINT.

I tested it so it works for me. (use it at your own risk since I'm not sure its ok)...