Giri, not yet. We will disable the "action oder checks" soon, but only in the SVN head, not in previous versions.
Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Kosuru, Giri [mailto:[EMAIL PROTECTED] > Gesendet: Montag, 6. März 2006 20:15 > An: Werner Dittmann; [EMAIL PROTECTED] > Cc: [email protected] > Betreff: RE: AW: Header element ordering iterop problem with .NET? > > Hi Werner, > > Are the modifications discussed in the following thread > incorporated into WSS4J? > > Thanks > Giri Kosuru > > -----Original Message----- > From: Werner Dittmann [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 22, 2005 2:33 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > 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:[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] > >>> > >>> > >>> > >>> > >> > >> > --------------------------------------------------------------------- > >> 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] > > --------------------------------------------------------------------- > 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]
