Christopher Dobbins

Greenhorn
+ Follow
since Dec 19, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christopher Dobbins

Ok so I wrote a custom handler that prints out the SOAP envelope in transport and stuck it as the last phase on OutFlow and the first phase on Inflow. Rampart is working correctly, and the header IS being added to the envelope.

The problem appears to be the weblogic server does not understand the <wsse:Security> header that rampart is building... which is why it doesn't process it correctly and throws the "MustUnderstand header not processed" fault. When I set mustUnderstand="false," obviously, I get a 403: Forbidden because the server cannot validate the client....

Is anyone out there REALLY good with Rampart and can suggest a way to swap out the implementation that builds the UsernameToken object? Maybe there is another library that might work better... or the guy who wrote the service is feeding me incorrect information when he said that the server needs only username/password authentication. I've tried "UsernameToken" and "UsernameToken Timestamp," neither work.
15 years ago
So... unfortunately when I set up my own test server and client w/ rampart and Axis2, it works seamlessly.

The problem is that I'm trying to write a client using rampart/Axis2 to work against a service generated with Weblogic 10. Should work fine, right?

I keep getting back a message from the server saying:

...AxisFault: MustUnderstand header not processed '{http://blah blah blah.xsd}Security'

If I remove the rampart portion of the client, I get back a 403: Forbidden code, and since when rampart is engaged it properly executes the callback to the PasswordHandler class, I am wondering if this is an interoperability problem between the client and server. If I turn the UsernameToken security on and then set WSHandlerConstants.MUST_UNDERSTAND to "false," I likewise get a 403: Forbidden.

I am completely stuck with no way to diagnose what is going wrong... it appears that my "diagnosis" of the header missing from the soap envelope was wrong, because it doean't call the password callback until axis is already handling the sendReceive, so it looks like it modifies the envelope somewhere in that method.

I wish there was a way to see my envelope in transport, but unfortunately I am not able to install any tcp monitors on my machine or anything of the like.

Has anyone ever seen that "MustUnderstand header not processed" error and understood what that means for the client?

As far as I can tell, the error means that the server was not able to process the header block I sent... the fact that the authentication fails completely when I set mustUnderstand to false seems to support this, but I could just be guessing... I'm not by any means a web services expert.

Just throwing this all out there in the hopes that someone else has had and solved this problem.
15 years ago
FYI, I misquoted a line of code before... the line I expect to see the soapenv:Header object present after is:

_serviceClient.addHeadersToEnvelope(env);

it does not change the envelope at all! doh!
15 years ago
Thanks for the warm welcome!

I will follow your example and see if it yields any answers, thank you.

-C
15 years ago
I used Axis2 WSDL2Java to generate a client stub, which works just fine and dandy against an unsecured version of the service.

However, I need to use simple UsernameToken for a "secured" version.

I have followed the rampart samples and tried to accomplish this both via a config file:

<module ref="rampart" />
<parameter name="OutflowSecurity">
<action>
<items>UsernameToken</items>
<user>userblah</user>
<passwordCallbackClass>client.PWCallbackHandler</passwordCallbackClass>
</action>
</parameter>

...as well as through an OutflowSecurity (deprecated) object:

OutflowConfiguration ofc = new OutflowConfiguration();
ofc.setActionItems("UsernameToken");
ofc.setUser("userblah");
options.setProperty(WSSHandlerConstants.OUTFLOW_SECURITY, ofc.getProperty());


...and additionally through the following VERY SIMPLE code:

ServiceClient sc = <stub>._getServiceClient();
sc.engageModule("rampart");
Options o = sc.getOptions();
o.setUsername("userblah");
o.setPassword("userpass");

I noticed I was getting "MustUnderstand header not processed" errors, so...

When I serialize my SOAPEnvelope before sending the message off (in the generated stub code), I notice that the soap envelope does not contain an <env:Header> element.... it's totally missing.

Furthermore, if I put a system.out in my password callback handler, the code executes. Why?

There is one line of interest in the generated stub:

_serviceClient.addSoapHeaders(env);

Serializing the envelope before/after that line yields identical, headerless envelopes, yet debug dissection of the _serviceClient object reveals that it contains the appropriate action items, username, password, etc. Furthermore, the rampart object is correctly engaging according to console output, and I get no errors from Axis2 or Rampart (other than the MustUnderstand from the server).

Why is the service client not adding the appropriate soap header??? This should be so simple!

Please, any help is appreciated, I've spent nearly two full days trying all sorts of things, and I'm tired of searching Google, to no avail.

What could I be doing wrong?

I'm using Axis2 1.4 w/ Rampart 1.4

-Chris
15 years ago