You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(plugin): add XML and SOAP request signing plugins - #14002
This accepts a SOAP Header that appears after the Body. SOAP 1.1 and 1.2 require the optional Header to precede the Body, so the plugin can report success while forwarding an invalid envelope that conforming upstreams reject. Reject this ordering during the existing envelope validation.
Prevent duplicate wsu:Timestamp in WS-Security
apisix/plugins/soap-signer/signer.lua:324
Because an existing wsse:Security block is reused, this unconditional append creates a second wsu:Timestamp when the incoming block already contains one. WS-Security profiles allow at most one Timestamp per Security header, and only the newly generated one is referenced by this signature, so common UsernameToken/Timestamp requests become invalid or ambiguous. Reject or replace an existing direct Timestamp before adding this one, or create a separate appropriately targeted Security block.
The reason will be displayed to describe this comment to others. Learn more.
Copilot review overview
🔵 Needs a closer look
XML diagnostics, WS-Security role handling, and per-request warning logging remain unresolved.
Review effort: Balanced Findings: None
Previously missed (1)
In code that hasn't changed since last review
Validate WS-Security role before selecting Security header
apisix/plugins/soap-signer/signer.lua:311
This still reuses the first wsse:Security element without checking its SOAP 1.1 actor or SOAP 1.2 role, or whether multiple Security elements make selection ambiguous. If the selected block targets another role (including SOAP 1.2 role/none), the generated signature is placed in a header the intended upstream receiver must ignore. Select only an unambiguous untargeted/ultimate-receiver block, or create/reject according to an explicit role policy.
Normalize configured media types before case-insensitive comparison
apisix/plugins/signing/request.lua:64
The request media type is lowercased, but configured media types are compared verbatim. Since media types are case-insensitive, a valid configuration such as Application/XML will reject an application/xml request with 415. Normalize each configured value before comparing it.
…ts in the expected test output'
add missing test parameters
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Stale body integrity headers survive body replacement
apisix/plugins/signing/request.lua:92
Replacing the body also invalidates end-to-end body integrity headers, but only length and transfer encoding are updated here. Requests carrying Content-MD5, Digest, Content-Digest, or Repr-Digest will reach the upstream with hashes for the pre-signing body and can be rejected or misrepresented as integrity-checked. Recompute these headers, remove them, or reject such requests according to an explicit policy.
Content-Type charset remains inconsistent with UTF-8 serialization
apisix/plugins/signing/request.lua:92
The signer serializes every successful result as UTF-8, but this rewrite preserves the original Content-Type parameters. A valid request such as text/xml; charset=iso-8859-1 is therefore forwarded with UTF-8 bytes still advertised as ISO-8859-1, so the upstream can misdecode or reject the signed document. Rewrite the charset to UTF-8 while preserving parameters such as SOAP action, or reject non-UTF-8 charset declarations before signing.
Trim media type whitespace before allowlist comparison
apisix/plugins/signing/request.lua:49
The captured media type retains whitespace before the first semicolon, so a valid header such as Content-Type: application/xml ; charset=utf-8 normalizes to application/xml and is incorrectly rejected with 415. Trim trailing optional whitespace from the captured type before comparing it with the configured allowlist.
Validate client-supplied wsu:Id values before signing
apisix/plugins/soap-signer/signer.lua:149
Any non-empty client-supplied wsu:Id is reused without validating the XML ID lexical form. For example, wsu:Id="a b" produces Reference URI="#a b", which is not a valid same-document ID reference and is rejected or resolved inconsistently by WS-Security verifiers. Validate existing values as NCNames and reject malformed SOAP before signing (or safely replace them while accounting for existing references).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Some upstream XML and SOAP services require signed request bodies. This PR adds APISIX plugins to apply those signatures before proxying requests.
xml-signerfor enveloped XML Digital Signatures.soap-signerfor WS-Security signatures on SOAP 1.1 and SOAP 1.2 requests.Checklist