Grzegorz, if this is the case (mustUnderstand headers MUST be processed in any case) then just comment the offendling lines the check for a Fault element. The normal processing takes place and the security handler does its job - the additional check you mentioned is not necessary in that case.
Regards, Werner > -----Ursprüngliche Nachricht----- > Von: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Gesendet: Freitag, 16. Dezember 2005 10:05 > An: Dittmann, Werner > Cc: [email protected] > Betreff: Odp: AW: Re: Odp: AW: AW: wsse:Security header and soap:Fault > > Werner, > > > thanks for this detailled analysis and report. What I'll > > check ist the follwoing: > > - when DoAllReceiver detects a "Fault" element it will check > > for security header with the appropriate actor and sets > > the properties for this header to "processed". This way > > the security headers do not trigger the MustUnderstandChecker > > It could be sufficient. Although maybe only marking the header as > "processed" > is not enough without actually processing it? > > I've looked in three specs: > > 1. Soap 1.1 W3C Note (2000-05-08): in section 4.2.3 it > states, that "if > header > is tagged .. mustUnderstand="1", the reciient MUST obey > the semantics, > or > MUST fail processing the message. > 2. Soap 1.2 Messaging Framework W3C WD (2003-06-24): in > section 2.4 it > states, > that "for every mandatory SOAP header targeted at node MUST either > process > the header or not process the SOAP message at all" > > It doesn't says anything about soap:Faults however :) > > Maybe the solution is in WS-I BasicProfile 1.0 (2004-04-16), > section 4.2 > "SOAP Processing Model"?: > Although in 4.2.3/R1028 there is "when a Fault is generated, further > processing > should not be performed" > There is also in 4.2.1/R1025: "A RECEIVER MUST handle > messages .. checking > of > mandatory headers is performed before any actual processing" > > My conclusion: soap:Fault stops message processing, but processing > mandatory > soap:Headers SHOULD be performed before any (including Fault) other > processing. > > > > > > Any thoughts? Shall we also ask the Axis guys what SOAP says > > about handling of headers in case of a SOAP "Fault"? > > I think we SHOULD :) > > > Regards > Grzegorz Grzybek > > > > > Regards, > > Werner > > > > > -----Ursprüngliche Nachricht----- > > > Von: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] > > > Gesendet: Freitag, 16. Dezember 2005 08:29 > > > An: Werner Dittmann > > > Cc: Dittmann, Werner; [email protected] > > > Betreff: Odp: Re: Odp: AW: AW: wsse:Security header and soap:Fault > > > > > > Hello. > > > > > > > strange behaviour at all. I'll try to get some info from the > > > > Oasis guys if in case of a SOAP fault the security headers > > > > should be processed. > > > > > > I would be very nice :) > > > > > > > > > > > > > > In you specific case I would suspect that the processing of > > > > that incoming security headers fail because you probably > > > > don't have the certificates or root certificates to verify > > > > the received Signature or to validate the certificate path. > > > > > > > > > > Let me summarize: > > > 1. In my test case, I've deployed a server with the > <responseFlow>'s > > > <parameter name="action" value="Timestamp Signature"/> > > > (WSDoAllSender) > > > - Client's <responseFlow> (WSDoAllREceiver) has the same > > > action parameter > > > set. > > > - When everything's OK, client's response handler > properly handles > > > all security headers (signature verification). SOAP response > > > contains wsse:Security header (mustUnderstand=1) > > > - When my WS method throws general AxisFault, everything's > > > still fine - > > > the SOAP response doesn't contains ANY soap headers, but > > > WSS4J 1.1.0's > > > WSDoAllReceiver skips processing it's configured > actions (Timestamp > > > and Signature) because of soap:Body/soap:Fault. > > > > > > 2. But in the case of .NET (1.1) + WSE (I think 2.0) > it's different: > > > - Client's <responseFlow> is the same (Timestamp Signature) > > > - I have not been able NOT to receive soap:Faults, but it > > > doesn't matter > > > :) > > > - The .NET WSE rejects my certificate ad signals it in > soap:Faults > > > (according to WSE 1.0/1.1 spec) > > > - But it also applies all wsse:Security elements in > soap:Header... > > > - standard WSS4J 1.1.0's WSDoAllReceiver detects soap:Faults > > > and returns > > > from invoke() > > > - eventually MustUnderstandChecker throws AxisFault with message > > > "Did not understand "MustUnderstand" header(s)" > > > > > > I think, that in case of server it should be almost > obvious that when > > > message > > > contains soap:Faults, there should be no security processing > > > (it's even > > > stated in > > > WSE 1.0 spec - "because of DoS and cryptographic attacks") > > > and generating > > > reposne > > > security headers. > > > But the client's WSDoAllReceiver SHOULD process all its > > > headers simply to > > > get rid > > > of the "Did not understand "MustUnderstand" header(s)" AxisFault. > > > > > > In my application (I must finish it today :) I simply put an > > > AND clause: > > > && WSSecurityUtil.findElement(root, "Security", > > > WSSE_NS_OASIS_1_0) == > > > null > > > while deciduig wether to quit WSDoAllReceiver's invoke()... > > > > > > Thanks for all the answers! > > > I'm looking forward to see how this would end (what would say > > > the Oasis > > > guys :). > > > > > > Best regards > > > Grzegorz Grzybek > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
