[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=17078684#comment-17078684 ] 

Peter De Maeyer edited comment on SANTUARIO-532 at 4/11/20, 8:33 AM:
---------------------------------------------------------------------

I've attached a patch which is already quite complete, but it probably won't be the final version yet so I suggest to keep an eye on the PR instead.


was (Author: peterdm):
I've attached a patch which is already quite complete, but it probably won't be the final version yet so I suggest to keep an eye on the PR instead (which I still need to create).

> 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)