You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org> on 2010/12/02 15:34:10 UTC
[jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on
the processing side if possible
Avoid converting the SOAP Body to DOM on the processing side if possible
------------------------------------------------------------------------
Key: WSS-257
URL: https://issues.apache.org/jira/browse/WSS-257
Project: WSS4J
Issue Type: Improvement
Affects Versions: 1.5.10
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.6
On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
The callback class could look something like:
public abstract class LookupCallbacks {
//for the wsu:ID, get the element
Element getElementForID(Object msgContext, String i) {
return null;
}
//for processing of MTOM things eventually
InputStream getAttachment(Object msgContext, String contentId) {
return null;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
Re: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on the processing side if possible
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday 02 December 2010 11:20:15 am Dittmann, Werner (NSN - DE/Munich)
wrote:
> Hi all,
>
> just a thought here: why is this necessary or should be done? Enhance
> performance? Reduce memory footprint?
Umm.. Both.
There are a bunch of usecases where this can have relatively huge benefits.
Some off the top of my head:
1) HTTPs used for "encryption", but there are ws-security headers (like SAML
tokens or username token and timestamps and such). In such case, there is NO
need for the body to be touched. If the soap bodies are large, this can
SIGNIFICANTLY reduce the memory footprint as very little is retained in a DOM
form.
2) Small soap messages, but LARGE attachments. To properly sign them, the
binary attachments must be pulled into memory, base64 encoded into a String
(keep in mind, UTF-16, so double the memory), and added to the DOM as a text
node. That is a LOT of extra memory. Ideally, we could keep the attachments
on disk. At least keep it in byte form and not String. Let Santaurio handle
the base64 encoding in small chunks that can be
signed/hashed/verified/whatever in smaller chunks and discarded.
3) Fail fast - kind of an optimization as well, but while processing the
username token or timestamp or something, if they fail (like the timestamp has
expired), we could fail immediately and not spend any time parsing and
processing the body.
4) Allow some extra non-SOAP usecases. This is a bit more obscure, but in
CXF, we've talked a little about how to leverage some of the WS-Sec stuff for
REST by having the security "header" in one mime part and the REST XML payload
in another or similar. By having the callback mechanism, we can avoid having
to construct a "fake" soap message to combine everything together and really
pass just what is needed into WSS4J as needed.
> Well, if I recall correctly then most of the processing time of WSS4J is
> spent in the crypto methods (public key processing in particular),
> signature processing and alike. IMHO tuning the DOM processing does not
> really enhance the performance and these changes may require quite some
> effort to do it.
The attachment stuff can be a HUGE performance thing for signature and crypto.
A large attachment right now can easily result in an OutOfMemory situation.
Working on optimizing that can be a big win.
Dan
>
> WDYT?
>
> Best regards,
> Werner
>
> -----Original Message-----
> From: ext Colm O hEigeartaigh (JIRA) [mailto:jira@apache.org]
> Sent: Thursday, December 02, 2010 3:34 PM
> To: dev@ws.apache.org
> Subject: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on
> the processing side if possible
>
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
>
>
> On an inbound request, WSS4J currently iterates through each security token
> in the security header and processes each one. However it also requires
> the entire SOAP request be converted into a DOM structure, even though it
> might not be necessary to access the SOAP body as part of processing the
> security header, e.g. processing a Timestamp, or a Username Token.
>
> This task is to enhance WSS4J on the processing side, so that it does not
> require access to the SOAP body. If it needs to find an element in the
> SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP
> body if required. This mechanism could potentially provide support for
> signed MTOM. WSS4J should supply a default implementation that more or
> less parallels the current implementation. CXF/Rampart etc. could define
> their own callback implementations for their specific needs.
>
> The callback class could look something like:
>
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
>
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
RE: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on the processing side if possible
Posted by "Dittmann, Werner (NSN - DE/Munich)" <we...@nsn.com>.
Hi all,
just a thought here: why is this necessary or should be done? Enhance performance? Reduce
memory footprint?
Well, if I recall correctly then most of the processing time of WSS4J is spent in the
crypto methods (public key processing in particular), signature processing and alike. IMHO
tuning the DOM processing does not really enhance the performance and these changes may
require quite some effort to do it.
WDYT?
Best regards,
Werner
-----Original Message-----
From: ext Colm O hEigeartaigh (JIRA) [mailto:jira@apache.org]
Sent: Thursday, December 02, 2010 3:34 PM
To: dev@ws.apache.org
Subject: [jira] Created: (WSS-257) Avoid converting the SOAP Body to DOM on the processing side if possible
Avoid converting the SOAP Body to DOM on the processing side if possible
------------------------------------------------------------------------
Key: WSS-257
URL: https://issues.apache.org/jira/browse/WSS-257
Project: WSS4J
Issue Type: Improvement
Affects Versions: 1.5.10
Reporter: Colm O hEigeartaigh
Assignee: Colm O hEigeartaigh
Fix For: 1.6
On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
The callback class could look something like:
public abstract class LookupCallbacks {
//for the wsu:ID, get the element
Element getElementForID(Object msgContext, String i) {
return null;
}
//for processing of MTOM things eventually
InputStream getAttachment(Object msgContext, String contentId) {
return null;
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Resolved] (WSS-257) Avoid converting the SOAP Body to DOM
on the processing side if possible
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh resolved WSS-257.
-------------------------------------
Resolution: Fixed
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] Commented: (WSS-257) Avoid converting the SOAP Body to DOM
on the processing side if possible
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966153#action_12966153 ]
Andreas Veithen commented on WSS-257:
-------------------------------------
@Dan,
WSS4J should call the method for every node. In the DOM case, the implementation would check for an Element with name xop:Include. In the Axiom case, it would check for a Text node, cast it to an OMText and check if it has a DataHandler.
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] Commented: (WSS-257) Avoid converting the SOAP Body to DOM
on the processing side if possible
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966148#action_12966148 ]
Daniel Kulp commented on WSS-257:
---------------------------------
I'm also kind of wondering if it should be:
Source getElementForID(Object msgContext, String i)
instead with a possible initial restriction of only DOMSource is allowed. At some point, it MAY make some sense for the incoming side to allow some level of streaming. Obviously, a LOT of changes would be required to do that.
Another question: does it need a flag to say what the use case is for? Signature or encryption? With encryption, we know the contents of the returned Source are irrelevant (will be replaced with the decrypted content), but for signature, it's just walking/checking. Thus, we could potentially optimize things differently in the two cases. Maybe I'm over thinking things. :-)
The encryption case may require an additional method like:
void replaceElement(Element encrypted, Element decrypted)
When the encryption has the entire Element encrypted (and not just the content), then it needs to be replaced. In the REST case we talked about on CXF, the encrypted element may not have a parent as it's not wired into a SOAP message. Thus, we wouldn't really have a way to find out if it was replaced or not unless we force the use of DocuementFragments or something.
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] Commented: (WSS-257) Avoid converting the SOAP Body to DOM
on the processing side if possible
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966141#action_12966141 ]
Andreas Veithen commented on WSS-257:
-------------------------------------
I think that the signature of the second method should be changed to something like this:
InputStream getAttachment(Object msgContext, Node node)
Rationale: In DOM/SAAJ, the optimized base64 data is represented as an Element (with name xop:Include), while Axiom represents it as an OMText node (referring to a DataHandler instead of a String). With the modified signature we should be able to support both models.
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] [Closed] (WSS-257) Avoid converting the SOAP Body to DOM on
the processing side if possible
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Colm O hEigeartaigh closed WSS-257.
-----------------------------------
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] Commented: (WSS-257) Avoid converting the SOAP Body to DOM
on the processing side if possible
Posted by "Colm O hEigeartaigh (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999407#comment-12999407 ]
Colm O hEigeartaigh commented on WSS-257:
-----------------------------------------
I committed an initial fix for this issue. I just created the simplest possible interface, plus a default implementation, which does not deal with attachments, or non-DOM elements.
Colm.
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org
[jira] Commented: (WSS-257) Avoid converting the SOAP Body to DOM
on the processing side if possible
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSS-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966144#action_12966144 ]
Daniel Kulp commented on WSS-257:
---------------------------------
Andreas: in the Axiom case, how would WSS4J even know to call the getAttachment method? I was kind of envisioning that if it encounters the xop:Include, it would call the getAttachment. But in the Axiom case, would the xop:include node ever be seen?
> Avoid converting the SOAP Body to DOM on the processing side if possible
> ------------------------------------------------------------------------
>
> Key: WSS-257
> URL: https://issues.apache.org/jira/browse/WSS-257
> Project: WSS4J
> Issue Type: Improvement
> Affects Versions: 1.5.10
> Reporter: Colm O hEigeartaigh
> Assignee: Colm O hEigeartaigh
> Fix For: 1.6
>
>
> On an inbound request, WSS4J currently iterates through each security token in the security header and processes each one. However it also requires the entire SOAP request be converted into a DOM structure, even though it might not be necessary to access the SOAP body as part of processing the security header, e.g. processing a Timestamp, or a Username Token.
> This task is to enhance WSS4J on the processing side, so that it does not require access to the SOAP body. If it needs to find an element in the SOAP request, it should use a callback mechanism, to obtain e.g. the SOAP body if required. This mechanism could potentially provide support for signed MTOM. WSS4J should supply a default implementation that more or less parallels the current implementation. CXF/Rampart etc. could define their own callback implementations for their specific needs.
> The callback class could look something like:
> public abstract class LookupCallbacks {
> //for the wsu:ID, get the element
> Element getElementForID(Object msgContext, String i) {
> return null;
> }
> //for processing of MTOM things eventually
> InputStream getAttachment(Object msgContext, String contentId) {
> return null;
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org