Grzegorz, see some questions/comments inline pls.
Werner > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 16. Dezember 2005 13:21 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Re: wsse:Security header and soap:Fault > > 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...), Werner: thus your web service (at the server) throws an exception? And this exception cases the onFault of the receiver handler? Hmmm..... > 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). Werner: agreed > > Second, the server (Axis+WSS4J) should always behave according > to its <service>/<responseFlow> wsdd definition. Werner: yes, anyhow we need to figure out how this could work with Axis. Seems that we have a problem (or we don't understand) with the Axis SOAP Fault handling. > 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]
