xenc:EncryptedKey in the wsse:Security header is opened with the enclosing wsSecurity element's keystore private key, and every xenc:EncryptedData it names is replaced by its plaintext.By default the accepted algorithms are narrower than what encrypt can be configured to produce: AES-128/256-GCM for content and RSA-OAEP with SHA-256 and MGF1-SHA-256 for the key. A message using anything else — an AES-CBC downgrade, RSA-1.5, or the modern OAEP URI carrying an SHA-1 mask generation function — is answered with wsse:UnsupportedAlgorithm before any cipher is constructed. That asymmetry is deliberate: what a peer may send is a separate decision from what this gateway emits, because accepting a padding-oracle-shaped algorithm exposes this gateway rather than the peer. allowedLegacyAlgorithms adds individual AES-CBC or RSA-1.5 exceptions for a peer that supports nothing else; the OAEP digest and mask generation function stay fixed either way.
One message, one recipient: a wsse:Security header carrying more than one xenc:EncryptedKey is refused rather than searched for the key this gateway can open. A multi-recipient message is a sender that addressed no header at any actor, and the fix for it is to target each header at the role meant to process it.
A message carrying no xenc:EncryptedKey is refused outright, so configuring this element already makes encryption mandatory. What requiredReferences adds is which elements had to arrive encrypted: without it, a peer that encrypted one trivial element and sent the rest of the message readable passes. List the elements that must have arrived encrypted to make confidentiality enforceable. See distribution/tutorials/web-services-security/70-Encrypt-And-Decrypt-Body.yaml.
Example Configuration
- wsSecurity:
keystore:
location: backend.p12
password: secret
keyAlias: backend
validate:
- decrypt:
requiredReferences:
- by: BODY
allowedLegacyAlgorithms: [aes256_cbc, rsa_1_5]
- wsSecurity:
keystore:
location: backend.p12
password: secret
keyAlias: backend
validate:
- decrypt:
requiredReferences:
- by: BODY
allowedLegacyAlgorithms: [aes256_cbc, rsa_1_5]
Syntax
decrypt:
allowedLegacyAlgorithms:
- aes128_cbc
requiredReferences:
- <wsSecurity-encrypt-reference>
decrypt:
allowedLegacyAlgorithms:
- aes128_cbc
requiredReferences:
- <wsSecurity-encrypt-reference>
Attributes
| Name | Required | Default | Description | Examples |
|---|---|---|---|---|
| allowedLegacyAlgorithms | false | - | - | - |
Child Structure
| Element | Cardinality | Description |
|---|---|---|
| wsSecurity-encrypt-reference | 0..* | The elements that must have arrived encrypted. Validation fails if any of them was sent in the clear. decrypt already requires every message to carry an xenc:EncryptedKey, whether or not this list is set; what it adds is which elements had to be among the ones that key decrypts — without it, a peer that encrypted one trivial element and sent the rest in the clear still passes. Each entry's type says how the element had to arrive, and has to match what the sender did: CONTENT requires everything inside the element to be ciphertext, ELEMENT requires the element itself to have been replaced by an xenc:EncryptedData. |