[jira] [Comment Edited] (SANTUARIO-532) User-defined and delayed evaluation of which XML elements need to be secured

["Peter De Maeyer (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SANTUARIO-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17115367#comment-17115367 ] 

Peter De Maeyer edited comment on SANTUARIO-532 at 5/31/20, 5:00 AM:
---------------------------------------------------------------------

The framework refactoring is done. I'll do the XPath implementation on another branch as a separate commit as you request. New patch attached.

* Removed all the deprecations.
* Introduced {{ElementSelector}} and {{SecurePartFactory}} without the XPath implementations.
* Removed the DOM elements from the {{ElementSelector}} API, and replaced them by the {{OutputProcessorChain}} which provides access to the {{OutboundSecurityContext}} in which specific implementation (such as the XPath one that I have in mind) may put implementation-specific parameter objects.

This new design will fully support the XPath implementation that I have in mind, while keeping it optional (only take the "overhead" when you need it). Instead of hardwiring the buildup of the DOM path in "the" output processor chain, it can implement it as a separate output processor.
* This new output processor will not be installed unless you use the XPath element selector implementation. The XPath element selector will thus be the trigger to install a cooperating output processor specifically for its purpose. The XPath element selector will thus implement {{ElementSelector.initialize(OutputProcessorChain)}} to install its own cooperating output processor.


was (Author: peterdm):
New patch attached.
* Introduced {{ElementSelector}} and {{SecurePartFactory}} without the XPath implementations.
* Introduced user-friendly builder {{SecurePartSelectorBuilder}} with factory method {{XMLSecurityProperties.addSecurePartSelector()}}.
* Removed the DOM elements from the {{ElementSelector}} API.

It's still a work in progress, but I'd like to get some feedback on it already.
I myself have some concerns I still would like to address with my XPath selector implementation in mind.

> User-defined and delayed evaluation of which XML elements need to be secured
> ----------------------------------------------------------------------------
>
>                 Key: SANTUARIO-532
>                 URL: https://issues.apache.org/jira/browse/SANTUARIO-532
>             Project: Santuario
>          Issue Type: Improvement
>          Components: Java
>    Affects Versions: Java 2.1.5
>            Reporter: Peter De Maeyer
>            Assignee: Colm O hEigeartaigh
>            Priority: Major
>         Attachments: SANTUARIO-532.patch
>
>
> As a user of the streaming API, I want to be able to define which elements need to be secured, and I want to be able to delay that evaluation until the streaming parser actually reaches that element.
> * The framework should offer an element selector for XPath expressions.
> * The framework should support user-defined element selectors.
> Currently, one has to define beforehand which elements need to be secured by adding a {{SecurePart}} (signature or encryption) to {{XMLSecurityProperties}}. The criteria based on which to select an element are fixed:
> # Based on {{QName}} only, no possibility to access ancestor or sibling elements.
> # Based on an attribute that must match an ID.
> # Based on whether the entire request needs to be secured: {{isSecureEntireRequest}}.
> This has several design flaws:
> * Inflexible. If a new criterion needs to be added, new methods need to be added to {{SecurePart}}.
> * The methods on {{SecurePart}} represent options which are mutually exclusive, yet they are present on the API: either use a QName or an 
> * No good separation of concerns. {{SecurePart}} is used both for input parameters and output parameters. In the common case, the QName defines "what to match", but in the case of {{isSecureEntireRequest}}, it is filled in by the framework "when the root element is matched", so it's a sort of output parameter.
> This improvement calls for a redesign of that API, whilst maintaining backward compatibility.
> Idea:
> * Add interface {{ElementSelector}} to let the user plug in their own implementation of when an element needs to be selected. The selection can be based on the parameters {{QName}} and the skeleton DOM {{Element}}.
> * The framework keeps track of a skeleton DOM element, which preserves element, attributes, and depending on a modifier, ancestors and siblings. 3 modifiers "node", "path" and "tree". "Path" is the default since it offers all ancestor information while still being memory-bounded. "Tree" keeps all siblings too, but is not memory-bound so to be used with care when the user knows what they're doing.
> * Add implementation {{XPathElementSelector}}, which allows selection based on XPath expressions.
> * Add interface {{SecurePartFactory}} to let the user create a {{SecurePart}} _upon selection_ (so _not_ beforehand). The creation can be based on the parameters {{QName}} and the skeleton DOM {{Element}}.
> * Refactor the framework to work with these new constructs internally.
> I have a PR ready, it's easier to explain in there. I fixed several bugs along the way, some were necessary, others weren't really necessary but are a change for the better. I can create separate JIRA issues for some of those if needed.
> To give some context: I needed streaming XML encryption in the product I'm working on in my professional life. I started using Santuario (2.1.4) because it is very promising, but still I had to overcome some limitations because it didn't fit our needs 100%. In my private time I'm now cleaning up the "hacks" I did in my professional career one by one, trying to promote them as contributions to the community.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)