You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Steve Green <st...@epok.net> on 2005/07/23 00:00:19 UTC
Signature validation regression
Developers,
At one time, and for quite some time, I've had a working web service
client that would receive a signed SAML assertion in the form of an
xsd:any, and be able to send that assertion back out, also in the form
of an xsd:any. Since my cvs up, it seems that no longer works properly.
On the surface, it seems that some xmlns attributes have been lost. I
see everything on the wire on the inbound, but on the outbound the
assertion is significantly different. It almost looks like someone is
optimizing xmlns attributes in MessageElement DOM. I assume that the
sax recorder will have everything, but I haven't actually tried
replaying into xerces DOM.
First, let me make sure that I understand what should be happening.
MessageElement can have many faces, and one such face is an
implementation of DOM. Should I expect that the xsd:any element (which
is a MessageElement) should have a complete DOM of what came in over the
wire? In the past, that has been the case.
Can anyone shed some light?
~S
Re: Signature validation regression
Posted by Davanum Srinivas <da...@gmail.com>.
The bug is "digital signature does not work". so it needs to be fixed :)
-- dims
On 7/25/05, Steve Green <st...@epok.net> wrote:
> On Mon, 2005-07-25 at 16:09 -0400, Davanum Srinivas wrote:
> > Please open a new bug with your sample code to recreate the problem.
> > Let's see if we can fix it for 1.3.
>
> The only question is whether this is 1 bug or 2. Is a MessageElement
> supposed to have a complete DOM representation of the xml?
>
> I've poked around a bit more and in SOAPHandler, I see this comment in
> addTextNode():
>
>
> ;
> þÿ
>
>
> ;;;;;
> ÿ
> Úìÿ
>
>
>
>
> :
>
> // we need to check the length of STRIPPED string
> // to avoid appending ignorable white spaces as
> // message elmenet's child.
> // (SOAPHeader and others does not accept text children...
> // but in SAAJ 1.2's DOM view, this could be incorrect.
> // we need to keep the ignorable white spaces later)
>
> Unfortunately, whitespace is not ignorable with digital signatures but
> assuming that the sax recorder is good, this is not really an issue.
> Unless otherwise asked to, I won't be opening a bug with this.
>
> ~S
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Signature validation regression
Posted by Steve Green <st...@epok.net>.
On Mon, 2005-07-25 at 16:09 -0400, Davanum Srinivas wrote:
> Please open a new bug with your sample code to recreate the problem.
> Let's see if we can fix it for 1.3.
The only question is whether this is 1 bug or 2. Is a MessageElement
supposed to have a complete DOM representation of the xml?
I've poked around a bit more and in SOAPHandler, I see this comment in
addTextNode():
;
��
;;;;;
�
���
�
:
// we need to check the length of STRIPPED string
// to avoid appending ignorable white spaces as
// message elmenet's child.
// (SOAPHeader and others does not accept text children...
// but in SAAJ 1.2's DOM view, this could be incorrect.
// we need to keep the ignorable white spaces later)
Unfortunately, whitespace is not ignorable with digital signatures but
assuming that the sax recorder is good, this is not really an issue.
Unless otherwise asked to, I won't be opening a bug with this.
~S
Re: Signature validation regression
Posted by Davanum Srinivas <da...@gmail.com>.
Please open a new bug with your sample code to recreate the problem.
Let's see if we can fix it for 1.3.
thanks,
dims
On 7/25/05, Steve Green <st...@epok.net> wrote:
> On Sat, 2005-07-23 at 05:12 -0400, Davanum Srinivas wrote:
> > can you set this in your server-config.wsdd?
>
> That didn't help, however after taking a deeper look at the problem, I
> think I now see what's broken.
>
> Setup:
>
> Axis client receives a message with a signed xsd:any element. The same
> client takes the signed element and sends it out to another server using
> xsd:any. The signatures are broken.
>
> Observed behavior:
>
> o During parsing of the first message, SAX events are stored in the
> recorder, and MessageElement objects are created. The insertion of the
> new MessageElements are setting _isDirty, and thus invalidating the
> recorder for serialization. It seems to me that it doesn't make sense
> to dirty the recorder during recording itself.
>
> o During creation of the MessageElements, some text nodes with newlines
> are lost. Assuming the recorder isn't invalidated, is it ok that the
> DOM face of MessageElements does not match what is in the recorder? In
> other words, is it ok that someone is throwing away the newline text
> nodes in the belief that the recorder will do the right thing during
> serialization?
>
> o The recorder has all of the text nodes.
>
> I am assuming that signatures could be made to work by either not
> dirtying the recorder or by not throwing away newline text nodes,
> however both seems like serious problems to me.
>
> NodeImpl.java has seen a bunch of activity in May. Backing out the last
> 4 commits restores the signatures, although I didn't try reapplying them
> one at a time.
>
> For reference:
>
> revision 1.16
> date: 2005/06/20 22:50:52; author: dims; state: Exp; lines: +2 -0
> Fix for AXIS-2068 - Missing setDirty flags in SAAJ tree modification
> (detachNode
> and setParent)
> from David Blevins
> ----------------------------
> revision 1.15
> date: 2005/06/09 16:36:27; author: venkat; state: Exp; lines: +3 -0
> Fix for AXIS-1960:
> - Added a new test case for TestSOAPBody.java to test for this bug.
> - added a call to setDirty(true) inside a few methods in NodeImpl
> - added setDirty(false) in getAsString() to fix ant all-tests errors.
> ----------------------------
> revision 1.14
> date: 2005/05/27 10:20:12; author: venkat; state: Exp; lines: +1 -6
> seems my last commit didnt make it to server. So repeating it again.
>
> Removing the call setDirty(true) fix the DOM serialization failures in
> ant all-t
> ests. Ideally, dirty flag should not cause serialization differences.
> But for no
> w, i have to remove this to fix some of the ant all-tests failures.
> ----------------------------
> revision 1.13
> date: 2005/05/24 03:55:24; author: venkat; state: Exp; lines: +6 -1
> Fix for the bug (try#2) : AXIS-1960 - SOAPPart.saveChanges() doesn't
> work.
>
> SOAPPart.writeTo(array) is put back again.
> call to setDirty(true) is added at required places in NodeImpl.
>
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
Re: Signature validation regression
Posted by Steve Green <st...@epok.net>.
On Sat, 2005-07-23 at 05:12 -0400, Davanum Srinivas wrote:
> can you set this in your server-config.wsdd?
That didn't help, however after taking a deeper look at the problem, I
think I now see what's broken.
Setup:
Axis client receives a message with a signed xsd:any element. The same
client takes the signed element and sends it out to another server using
xsd:any. The signatures are broken.
Observed behavior:
o During parsing of the first message, SAX events are stored in the
recorder, and MessageElement objects are created. The insertion of the
new MessageElements are setting _isDirty, and thus invalidating the
recorder for serialization. It seems to me that it doesn't make sense
to dirty the recorder during recording itself.
o During creation of the MessageElements, some text nodes with newlines
are lost. Assuming the recorder isn't invalidated, is it ok that the
DOM face of MessageElements does not match what is in the recorder? In
other words, is it ok that someone is throwing away the newline text
nodes in the belief that the recorder will do the right thing during
serialization?
o The recorder has all of the text nodes.
I am assuming that signatures could be made to work by either not
dirtying the recorder or by not throwing away newline text nodes,
however both seems like serious problems to me.
NodeImpl.java has seen a bunch of activity in May. Backing out the last
4 commits restores the signatures, although I didn't try reapplying them
one at a time.
For reference:
revision 1.16
date: 2005/06/20 22:50:52; author: dims; state: Exp; lines: +2 -0
Fix for AXIS-2068 - Missing setDirty flags in SAAJ tree modification
(detachNode
and setParent)
from David Blevins
----------------------------
revision 1.15
date: 2005/06/09 16:36:27; author: venkat; state: Exp; lines: +3 -0
Fix for AXIS-1960:
- Added a new test case for TestSOAPBody.java to test for this bug.
- added a call to setDirty(true) inside a few methods in NodeImpl
- added setDirty(false) in getAsString() to fix ant all-tests errors.
----------------------------
revision 1.14
date: 2005/05/27 10:20:12; author: venkat; state: Exp; lines: +1 -6
seems my last commit didnt make it to server. So repeating it again.
Removing the call setDirty(true) fix the DOM serialization failures in
ant all-t
ests. Ideally, dirty flag should not cause serialization differences.
But for no
w, i have to remove this to fix some of the ant all-tests failures.
----------------------------
revision 1.13
date: 2005/05/24 03:55:24; author: venkat; state: Exp; lines: +6 -1
Fix for the bug (try#2) : AXIS-1960 - SOAPPart.saveChanges() doesn't
work.
SOAPPart.writeTo(array) is put back again.
call to setDirty(true) is added at required places in NodeImpl.
Re: Signature validation regression
Posted by Davanum Srinivas <da...@gmail.com>.
can you set this in your server-config.wsdd?
<parameter name="enableNamespacePrefixOptimization" value="false"/>
take a peek at
ws-axis\java\src\org\apache\axis\server\server-config.wsdd
-- dims
On 7/22/05, Steve Green <st...@epok.net> wrote:
> Developers,
>
> At one time, and for quite some time, I've had a working web service
> client that would receive a signed SAML assertion in the form of an
> xsd:any, and be able to send that assertion back out, also in the form
> of an xsd:any. Since my cvs up, it seems that no longer works properly.
>
> On the surface, it seems that some xmlns attributes have been lost. I
> see everything on the wire on the inbound, but on the outbound the
> assertion is significantly different. It almost looks like someone is
> optimizing xmlns attributes in MessageElement DOM. I assume that the
> sax recorder will have everything, but I haven't actually tried
> replaying into xerces DOM.
>
> First, let me make sure that I understand what should be happening.
> MessageElement can have many faces, and one such face is an
> implementation of DOM. Should I expect that the xsd:any element (which
> is a MessageElement) should have a complete DOM of what came in over the
> wire? In the past, that has been the case.
>
> Can anyone shed some light?
>
> ~S
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/