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

["Colm O hEigeartaigh (Jira)" <ji...@apache.org>]

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

Colm O hEigeartaigh commented on SANTUARIO-532:
-----------------------------------------------

I want the existing approach of securing XML for the streaming code to work seemlessly for users. So that means, not deprecating methods that are simple to use and replacing them with more complicated ways of securing the request. I don't want to impose any DOM-like code on users of a streaming API, when it's only needed for one particular use-case. I definitely don't want to impose any extra steps (ascend/descend) just to cater for a new use-case.

I'm not interested in arguing any of the points above, as my time with this project is limited. Any new functionality shouldn't make the existing functionality harder to use, or slower. Ideally what we want is to abstract the API a bit, so that the new functionality can just plug in to it.

So the question is, given the above, how can we move forward with this task, bearing in mind that time is limited before the 2.2.0 release goes out? IMO it would be best first to have a patch to refactor the API a bit, so that the newer functionality can plug in to it.

 

> 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
>             Fix For: Java 2.2.0
>
>         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)