Paul Sandoz wrote:
> Thinking about this a bit more i am not sure it is strictly required.
>
> In general i presume that verifying a signature will only be performed
> on a stream or SAAJ-based message. And for the latter case the
> SAAJ-based message will have been created (because of policy) so that
> the security pipe will obtain the whole SOAPMessage from the message,
> and thus will not use such a method on header.
>
> In this respect it easy for the header implementation and security to
> use the XMLStreamReader and nothing extra needs to be done with any
> implementations.
I was wondering about the same thing on the way back home yesterday.
I was following up with the discussion note I sent out about security
requirements, and this was listed there, so that's why I added it.
Quoting the relevant part of the minutes below:
> Kohsuke Kawaguchi wrote:
>> > My minutes of the discussions
>> > =============================
>> >
>> > - attributes and namespace declarations (IOW the whole infoset) of the
>> > <S:Body> element needs to be made available for security. At a casual
>> > glance this requires a new method on Message.
> +1.
> writeBody() and writeBodyContent() instead of writePayLoad ?
>> >
>> >
>> > Kohsuke noted that it's available by playing the XML infoset of the
>> > whole message --- since the security pipe (SP) will be then performing
>> > some operation on the data, wouldn't this be suffice?
>> >
>> >
> if you mean writeTo() ,well we may not want to do this for performance
> reasons. We need some experiments before we commit on any of the
> approaches. I will do this.
> I am working on streambuffer right now will let you know.
I now realize that in later algorithm discussion, we agreed upon
"<<Algorithm A>>", which I believe didn't require any such method like
getAttributeValue.
I guess I'll have to clarify Venu one more time.
> I suppose having such a method is mildly more efficient since an
> XMLStreamReader instance does not need to be retained. e.g. this:
Yeah, but this is only added for the security pipe and if they aren't
going to use it, I think it might be better not to have it. For many
message implementations (like JAXB), this isn't very cheap. Besides, for
the security component, once it finds an ID, it will want to play the
infoset, so they might want to access XMLStreamReader anyway.
> We also need similar functionality on Message. The security pipe needs to:
>
> - get the attributes on the SOAP body; and
>
> - serialize out the SOAP body and payload canonically.
>
>
> So we would need:
>
> String getAttributeValue(String nsUri, String localName);
>
> or:
>
> XMLStreamReader readSoapBodyAndPayload();
>
> In addition to:
>
> void writeSoapBodyPayloadTo(XMLStreamWriter sw)
Right. That's another reason I didn't feel very comfortable adding the
Header.getAttributeValue method, as we'll also need to have those
methods added on Message, which makes a Message implementation more tedious.
But I'm confused. Do you think we should have all those, or do you think
we should get rid of Header.getAttributeValue?
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com