Re: AW: Header element ordering iterop problem with .NET?

[Allen Cronce]

Hi Werner, I'm trying to understand why enforcing the order of all actions is a security enhancement. The security of WSS comes from a well thought out spec, the strength of the underlying crypto algorithms, and careful use by the implementor. After all, if you mix up the order of the elements, the digests and digital signatures still have to match. The only case I can think of where ordering might be important is when a given action transforms data, like encryption or decryption. If that's the real issue here, then maybe the right implementation is to enforce the order of encryption relative to the rest of the actions. But actions that do not transform data should not be order sensitive. Certainly it just doesn't matter where a timestamp element appears in the header, for example. If I'm missing something here, please elaborate. Shorter term, it looks like I'll have to go the override approach. From a practical standpoint, I want one service and need to get this working soon. Best regards, -- Allen Cronce Dittmann, Werner wrote: Allen, IMHO you have several option here: - create a new binding/service name in the Axis deployment that the .Net clients use and adapt the order of actions (WSS4J does not need a specific order during receive of a request, the check is only to to enhance security) - you may overwrite the code Question to the community: WSS4J already supports a "NoSecurity" parameter. However, this only controls how the handler works if _no_ security header/security actions were found at all. Shall we enhance this to switch of/modif security checking? If yes: are there some ideas? Regards, Werner -----Ursprüngliche Nachricht----- Von: Allen Cronce [mailto:[EMAIL PROTECTED]] Gesendet: Montag, 21. November 2005 08:03 An: wss4j-dev@ws.apache.org Betreff: Header element ordering iterop problem with .NET? Hi all, My service is configured with an action value of "Timestamp Signature". I've specified in the signatureParts to sign the timestamp and the body. The idea behind the signed timestamp is that we can use it at a higher level in our service to prevent replay attacks. This configuration works great with a test client built from Axis and wss4j. But it does not work with a test .NET client. In the .NET case, we get an "actions mismatch" error in WSDoAllReceiver on the server. I've compared the soap and noticed that the .NET generated version has the timestamp element before the signature. Whereas in the working case, the signature element precedes the timestamp. My web searching results regarding this problem indicate that wss4j is enforcing an order to the elements in the header. But apparently the spec doesn't require this. Sure the prepending rule makes sense. But other than the fact that ordered elements are more clear and easier to process, I don't see any rationale to enforce any order. It does nothing to enhance security. All it does is hurt interoperability with other implementations that, as per the spec, don't bother to order their elements in a sensible manner. Assuming that the above is accurate, what's the best way to proceed? Do I need to override the code to perform a non-ordered comparison? Best regards, -- Allen Cronce --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]