[jira] [Resolved] (AXIS2-6108) WS-Addressing decoupled responses are refused by default from 2.0.2

     [ 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)