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

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: Java 2.1.5
• Component/s: Java
• Assignee: Colm O hEigeartaigh
• Reporter: Peter De Maeyer
• Created: 08/Apr/20 20:16
• Updated: 11/Sep/23 05:52

Description

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:

1. Based on QName only, no possibility to access ancestor or sibling elements.
2. Based on an attribute that must match an ID.
3. 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.

Issue Links

• depends upon: SANTUARIO-534 DOMNamespaceContext does not implement the NamespaceContext contract correctly
• depends upon: SANTUARIO-535 Remove useless method AbstractOutputProcessor.processEvent
• relates to: SANTUARIO-536 SecurePart.getIdToSign is misleading since it's used for both signature and encryption
• relates to: SANTUARIO-538 SignatureCreateReferenceURIResolverTest gives false positives
• relates to: SANTUARIO-537 Parameter disAllowDocTypeDeclarations is incorrectly camel-cased
• links to: GitHub Pull Request #12
• links to: GitHub Pull Request #13