[
https://issues.apache.org/jira/browse/AXIS2-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Lazarski resolved AXIS2-6108.
------------------------------------
Fix Version/s: 2.0.2
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 2.0.2
>
>
> 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]
