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]
|
