Werner,
> Grzegorz, all
>
> well, in that case you may have a security problem :-).
>
> After reading SOAP 1.2 specs again I came to the same
> conclusion as you: Header processing for "mustUnderstand"
> headers is *always necessary* even in case the SOAP Body
> contins a Fault block.
>
> What follows is:
> 1st: if a client requires Security (as defined
> in WSDD) for a response then the server must generate
> Security headers with appropriate information in *any* case.
> This fact must be known to the server (Security Policy)
I looked again at the case, when WS method deployed on my test
Axis+WSS4J (with responseFlow defined with "Timestamp Signature" actions)
threw an AxisFault.
After throwing AxisFault, Axis engine started notifying the hadlers by
calling their onFault() method. One of the handlers was WSDoAllReceiver
(why receiver? - we have already turned from request to response flow...),
but its onFault() method (in base class) was empty...
I think that's why the response did not contain the (declared in
<responseFlow>!)
wsse:Security soap header...
The client worked fine only because its WSDoAllReceiver stopped processing
the message after smartly (and against WS-I Basic Profile?) detecting the
soap:Body/soap:Fault element.
Commenting this snippet of code caused "Request does not contain required
Security header" AxisFault.
I think, that it's server's problem with not exetuting declared
(in responseFlow) actions "Timestamp Signature".
Client works fine, but should process wsse:Security headers.
>
> 2nd: even if the Security handler at the server rejects
> some Security stuff, for example the signature verification
> fails, then the Fault response to the client must be
> "Security" processed according to the security requirements
> (policies) of both parties.
Agree. But why Axis (1.3) calls WSDoAllReceiver.onFault() instead (?)
of WSDoAllSender.onFault()?
There should be a way of acting according to <responseFlow> or some
kinfd of WS-Policy declarations.
>
> Thus, if your client receives a Fault message and you have
> defined Security actions in the response flow then the Fault
> *must* contain Security header blocks - otherwise you get a
> Fault "no Security" from the receiver handler. According
> to the specs this seems to be the correct behaviour.
> I admitt in that case you may not see the real (server side)
> fault because it may be overlayed with the fault generated by
> the Receiver handler.
That's the point!
In my test case, the WS method threw AxisFault("message") exception
and it appeared in client's logs in plain soap:Envelope (without
security headers), but client catched AxisFault("Request does not
contain required Security header") exception losing my server exception.
> Well, now i'm getting confused now :-).
Me too :) - I wonder what the Oasis guys will say (and maybe
WS-I guys) :)
>
> Any thaughts how to handle this? All are invited to smash
> in their ideas how to handle this topic.
First, the WSDoAllReceiver at client's side should always process
any soap:Headers that may be processed (and are mandatory).
Second, the server (Axis+WSS4J) should always behave according
to its <service>/<responseFlow> wsdd definition.
Accepting plain soap without security headers (at client side)
and not generating security headers at server side in case of
AxisFault COULD be an inner agreemetn between Axis+WSS4J client
and Axis+WSS4J server, but it's simply NOT interoperable.
Regards
Grzegorz Grzybek
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
