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

["Kosuru, Giri" <Gi...@associates.dhs.gov>]

Hi Werner,

	Are the modifications discussed in the following thread incorporated into WSS4J?

Thanks
Giri Kosuru

-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de] 
Sent: Tuesday, November 22, 2005 2:33 PM
To: acronce@earthlink.net
Cc: wss4j-dev@ws.apache.org
Subject: Re: AW: Header element ordering iterop problem with .NET?

Allen

the receiver implictly checks _all_ security actions within a Security
header. The use of the action parameter at the reciver side is mainly
to know which further parameters to parse (crypto property, certificate
names, etc.). Thus the validation of the action is only for the
sequence of the security actions.

The action sequence check were introduced in the very first version
of WSS4J to match some requirements of the WSS spec back in 2003 (as
far as I can remember).

Maybe you can just mail your modifications, I can incorporate them into
the code.

Regards,
Werner

Allen Cronce wrote:
> Hi all,
> 
> As indicated below, I've worked around this issue by overriding. My
> service is now compatible with .NET.
> 
> But unfortunately since there's no method that specifically validates
> the actions, I had to override the entire invoke method of
> WSDoAllReceiver. This has me nervous regarding future maintenance and
> compatibility with the WSDoAllReceiver class.
> 
> So rather than just copy the invoke method in my override class, I've
> cut the action validation code out of the invoke method and placed it in
> its own method. In the new method, I've got a fake decision point where
> it either executes the old code that verifies the order, or the new
> orderless compare. I've added a TODO that indicates that a property
> should be added to determine which compare to perform.
> 
> If this code (or something like it) was merged into the current code
> base, then in the future people like me who want to just affect how
> actions are validated could override a single simple method. This would
> reduce maintenance and supportability headaches moving forward.
> 
> Should I file a Jira enhancement with this code? Or is it too early to
> determine which way the community wants to go regarding the action
> comparison interoperability issue? I'm still of the mind that the
> current implementation where the order is strictly enforced is not spec
> compliant and should be changed.
> 
> Best regards,
> --
> Allen Cronce
> 
> 
> Allen Cronce wrote:
> 
>> 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:acronce@earthlink.net] 
>>>>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: wss4j-dev-unsubscribe@ws.apache.org
>>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>>
>>>>
>>>>    
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
>>>For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>>>
>>>
>>>  
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org For
>> additional commands, e-mail: wss4j-dev-help@ws.apache.org 
> 
> 
> --------------------------------------------------------------------- To
> unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org For additional
> commands, e-mail: wss4j-dev-help@ws.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org