[
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: [email protected]
For additional commands, e-mail: [email protected]
