Robert Maier wrote: > Now, on to the issue: For the request flow, if the client handler > specifies as action "Signature" and the service handler expects > "Signature Encrypt", the client sends a signed message, the signature > is verified at the server side and the message gets delivered to the > service, although the message is not encrypted as expected. The same > happens in the opposite direction as well. Yes, I agree that this is an issue, though I would suspect that flipping your scenario a bit is more troublesome. To wit, suppose a message comes in encrypted but not signed, but the message consumer requires integrity protection. You might want to reject the request (or response, as the case may be) right there. (Requiring encryption is certainly important and laudable, but the "cat is out of the bag", as it were, if the message is sent without confidentiality protection).
I am not an expert on Axis, but at a minimum the information about what occurred (the "results" from processSecurityHeaders) should be propagated up the stack through some sort of request context (good ol' Current). Perhaps that would mitigate your concerns? > > Although it might be nice as a feature (see my previous post), I am > afraid it is a bug and an exception should be thrown/fault should be > returned (something like WSDoAllReceiver: security processing failed > (actions mismatch)). > > What would the verdict be: bug or feature? I would hesitate to call this a bug, per se. It's a valid enhancement request, however. > > Cheers, > Robert. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
