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: [email protected]
> 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]

Reply via email to