Robert Lazarski created AXIS2-6108:
--------------------------------------
Summary: WS-Addressing decoupled responses are refused by default
from 2.0.2
Key: AXIS2-6108
URL: https://issues.apache.org/jira/browse/AXIS2-6108
Project: Axis2
Issue Type: Task
Reporter: Robert Lazarski
This feature is now disabled by default in 2.0.2 and beyond:
WS-Addressing decoupled responses occur when a web service sends a reply back
through a completely separate network connection rather than reusing the
original request connection. The client specifies a distinct destination
address using the standard wsa:ReplyTo SOAP header, allowing requests and
responses to operate asynchronously.
See explanation below, and how to manually enable the feature if desired:
A non-anonymous `wsa:ReplyTo` or `wsa:FaultTo` makes the server open an outbound
connection to an address the caller chose. From 2.0.2 that is refused unless the
deployment opts in, so replies travel back down the inbound connection only.
This is a behaviour change and will break deployments that rely on decoupled
responses. It is recorded here so it appears in the release notes rather than
being discovered at upgrade time.
*Symptom after upgrading*
Replies stop being sent and the following appears in the log at WARN:
Rejecting non-anonymous WS-Addressing response endpoint: <address>
*Restoring decoupled responses*
Set in `axis2.xml`, or per service in `services.xml`:
<parameter name="allowNonAnonymousResponseEndpoints">true</parameter>
Enabling the feature does not restore the previous behaviour in full. Three
further parameters apply:
| Parameter | Default | Effect |
|---|---|---|
| `allowedResponseEndpointSchemes` | `https` | Schemes a reply may use. A
deployment replying over anything else must name it, e.g. `https,http` or
`https,tcp`. |
| `blockPrivateNetworkResponseEndpoints` | `false` | When true, additionally
refuses loopback and private ranges. Off by default because a callback inside
the same private network is how most decoupled deployments are wired. |
| `responseEndpointResolveTimeoutMillis` | `2000` | Bound on the name lookup
used to screen the destination. |
Link-local, wildcard and multicast destinations are refused whatever these are
set to, and redirects are not followed for a decoupled response.
*Why the default changed*
The egress is spec-sanctioned — WS-Addressing section 7.1 leaves endpoint
authority checking to the implementor — but addressing is engaged by default in
the shipped `axis2.xml`, so a stock deployment had this surface open. Apache CXF
made the same call in 2026, disabling decoupled destinations by default. Axis2
needs no equivalent of CXF's WS-RM carve-out, since Sandesha is no longer part
of the project, so there is no bypass property here.
*Notes*
- The check runs both where the inbound header is parsed and where a server-side
response acquires its transport, so setting the endpoint reference
programmatically does not reach around it.
- Known limitation: the destination is resolved once to screen it and again to
connect, so a hostile DNS server could answer differently the second time.
Closing that needs the transport to connect to a pinned address, which it does
not currently support. Pair these settings with network egress controls.
- Documented under "Existing Security Hardening" in `SECURITY.md`.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
