|
From: Ng C. Y. [Cyng] <cy...@cs...> - 2003-05-05 03:47:57
|
Hello,
> > one issue is with the soap namespace prefix. I've nailed this down to the
> > fact that hermes passes the doc to xmlsec as a DOM tree, rather than as a
> > string. When passing this to xmlsec, reserialization uses SAAJ, which
> > hardcodes 'soap-env' as the prefix, while the others use SOAP. this
> > causes a digest mismatch. I've solved this (for now) by swapping to SOAP
> > as the prefix in SAAJ and Hermes, but we need to change this so that the
> > actual streamed data is passed to XMLSignature in xmlsec.
> Our business partner's incoming messages are not being validated, and I'm
> wondering if it's because they use "SOAP-ENV" as a prefix. I'll try
> hacking Hermes to use "SOAP-ENV" as well.
Let me summarize the findings on xmlsec, JAXM and Axis so far.
JAXM with xmlsec:
- Hermes sends signed message : the signed message should be correct
*if* xmlsec's algorithms such as digest, canonicalization are
implemented correctly, i.e., it should be verified by non-Hermes
MSH. The reasons why I say so are that: (1) JAXM uses "soap-env" as
the SOAP envelope prefix no matter what is set in
NAMESPACE_PREFIX_SOAP_ENVELOPE. After the transformation from JAXM
tree (dom4j) to DOM tree, every element nodes and text nodes should
be preserved (I ever examined) such that xmlsec should sign the
correct message as I also followed exactly the signing example.
(2) After signing, Signature element from DOM tree is re-inserted back
to JAXM tree. I examined the serialization of JAXM tree should look
the same as the DOM tree after canonicalization. So I expect the signed
message can be verified by non-Hermes MSH.
- Hermes receives signed message : If the received signed message is
generated by Hermes, that's ok for sure. Otherwise, problems happen.
If the signed message, say, has "SOAP-ENV" as envelope prefix, JAXM
always represents this as "soap-env" internally. No matter the JAXM
tree is transformed or printed out as String, the message changes to
use "soap-env" prefix so that verification must fail. Currently, I
have no idea to patch anything at all. The conclusion seems to be that
JAXM with xmlsec fails to verify non-Hermes messages.
Axis with xmlsec:
- Hermes sends signed message : everything is preserved after
transformation from Axis tree to DOM, and after re-insertion of
Signature from DOM to Axis tree, i.e., the siging process should be
correct. However, when the message is serialized by calling writeTo()
finally, the Axis tree is beautified by adding extra "\n" and spaces
which obviously voids the signature. Currently, I don't know how to
disable the Axis setPretty() function. I ever asked in Axis mailing
list and it seems that some tricky ways of calling org.apache.xxx.xxx
should be called to control the formatting but my feeling is that this
will be very implementation dependent and one is not calling the
standard JAXM interface. (I ever find other bugs in Axis that I will have
to report soon.) Another idea is to serialize the unsigned the message
first as String and then sign this String. Hopefully, after signing,
the serialization stream may look identical before signing. I haven't
tested this but this is quite hacked as well in my personal view.
- Hermes receives signed message : For non-Hermes signed message, the
Axis tree preserves all namepsace prefixes no matter for SOAP envelope
or Signature, i.e., it seems ok for you to use "SOAP-ENV" or "dsig".
I use your dumped sample and certificate to test. Sigh.... digest
verification for URI="" and URI="xxx" is ok while the signature values
fails. I don't know why yet.
You see. Really "good" enough to use and investigate these kinds of
libraries. I am very sorry that this causes problems to your testing or
productions cases. But the way is really hard. Currently, I just focus on
Axis and I just hope one solution works first.
Regards,
CY
----------------------------------------------------------------------------
Ng Chi Yuen, CY. cy...@ce... http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------
|