Dunno but IMO the ordering of wsse elements shouldn't matter as long as the signature checks out ok.
If .NET service is relying on elements being before this and that, then this service is broken and non-compliant. I know that is kinda empty advise if you are running against something out of your control...so here are my 2 cents: If you use the old OutflowConfigurtion() structures which are deprecated but not yet removed, there is an order you can define you actions: "Timestamp Signature" or "Signature Timestamp". I have no idea if it will affect the actual elements order but it might be worth trying. Just on a general note to the rampart and wss4j devs: I wish this is not removed (since its deprecated) until ALL interop scenarios are proved between the Neethi and the old config way. George -----Original Message----- From: Tim Munro (myDIALS) [mailto:[EMAIL PROTECTED] Sent: Thursday, June 21, 2007 3:45 PM To: [email protected] Subject: RE: Rampart X509 Signature Rejected by .NET Web Service FYI - my investigation is ongoing, however I am wondering if the issue may be that the Java client inserts the Timestamp into the bottom of the Security header (below the BinarySecurityToken and Signature), however the .NET client inserts this at the top. Does anyone know how I can force Axis/Rampart to place the (signed) Timestamp element at the top of the Security header? Thanks, Tim. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
