Is there someone that can point me out a clear tutorial (or give me some hints) how I can enable the binary security token profile with WSS4J and axis ? WSS4J really lacks a good documentation. The samples only deal with the username token .
WSS4J 1.1 comes with some unittest code that uses binary tokens programmatically (TestWSSecurity11.java). (I would guess that the current version 1.5 does, too.) You could run that, and use TCPMon to observe whether the SOAP transferred over the wire matches what this article describes.
This article has some Java code examples. [ May 10, 2006: Message edited by: Ulf Dittmer ]
Ping & DNS - updated with new look and Ping home screen widget
Joined: Sep 24, 2004
I already found that info on xml.com, but it sounds very, very manually and very, very bad practise ?
The code uses a SignatureToken class which extends token and next a BinarySecurityTokenWithReference class that extends SignatureToken. There are three things that I don't coop with:
- The code is very messy and has 'catch Exception' all over the place - It uses String concatentation for appending the signed information (this can't be the way to do it ?) - Why should we provide this kind of classes ? If we do all this work ourselves, well, then I don't need wss4j, I just append the security XML in the SOAP myself then ?
Maybe its just me, but it seems weird.
Next, I also see that wss4j has a class called "X509Security" which extends BinarySecuroty ... I don't know what it does, but I think thats the class I need.
Now, I still don't see how to glue this together with axis. Even if I use those classes from XML.com I would still need axis configured to use it. But how ? ...
Joined: Mar 22, 2005
The code is very messy and has 'catch Exception' all over the place
It's just example code that needs to be adapted to the specific circumstances anyway.
It uses String concatentation for appending the signed information (this can't be the way to do it ?)
The binary token is outside the standardized methods like username/password and signature tokens. Since WSS4J knows nothing about the token, it can't generate that info itself. You could of course use DOM, XOM, JDOM, dom4j ... to generate this XML fragment.
Why should we provide this kind of classes ? If we do all this work ourselves, well, then I don't need wss4j, I just append the security XML in the SOAP myself then ?
There's lots more that WSS4J does, which you'd also need to do by hand. Note that this class does not generate all the WSS stuff, just the one element that encapsulates the token.
But you're absolutely right, WSS4J suffers badly from missing documentation and examples. I'm still trying to figure out what's new in the recently released version 1.5, short of going through CVS logs or reading through the complete archive of the developers mailing list.