SOAP client wiring references old bean ID

Wiring: Yes, it’s exactly the same literal pipeline bean for all 3 SAML SOAP client cases: Artifact decoder, Logout and AttributeQuery. See the factory bean mapping config SOAPClient.PipelineFactory.LocatorMapin soap-client.xml. All 3 are literally aliases to the same concrete one. (Or will be - query isn’t checked in on main yet, just my local branch).

I could probably test “manually” with some kind of ginned up client test. I think I did this way back when I worked on the artifact decoder. Of course, would be better to have a unit test. If we have all the test harness support kind of stuff in the IdP unit tests, I think would not be hard. Can either mock the actual HttpClient to just return a static response or use an embedded Jetty.

SOAP decoder: Yeah, the problem is obvious now. I don’t remember when/why we made the handlers init-able, but we missed this case obviously. I think the wired ones in soap-client.xml are fine, since we define the default-init-method there. So it’s likely just the one created in code that you found (actually 2 places for both SAML 1 and 2).

Easy enough to fix. Only complication is that those are created in the decoder ctors and initialize() throws a checked exception, so throwing that back out would change the behavior. The body handler init can’t actually fail - there is no impl other than the base class - so for now I will just wrap the ComponentInitializationException in a SAMLRuntimeException to surface without changing the signature. We can change if there is a better way.

Looks like this call in org.opensaml.saml.saml1.binding.decoding.impl.HttpClientResponseSOAP11Decoder is injecting a “body handler” by creating it internally but not initializing it, that would be at least part of the problem, if not all.

Next stack trace after that fix:

I vaguely recall some kind of change related to message handlers and component APIs but I do not recall the specifics. It could be that got added, and the problem is handlers that are embedded in handler chains aren’t being auto-init’d by Spring.

Did you actually get to a point of exercising any of this wiring with the query connector or was that still off in the future? Or is it separate wiring?

The initial/obvious issue was fixed, but we’ll need testing, there are probably some other issues in there.