<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Ok, I've posted something out in the repo
putmanb/soap-client-examples.<br>
<br>
There are 2 concrete examples: 1) SAML 2 AttributeQuery 2) CAS
samlValidate. Actually, they are both very similar, but I went ahead
and did both. I didn't get fancy with the argument inputs on the
executable classes, there are just static fields on the class, so
change URLs etc to suite what you want to run against. I may
eventually fancy up with cmd-line args. Or more likely, do a full
Spring Boot ApplicationRunner thing, with properties, etc. Mostly I
just wanted to get the code and Spring examples out there for now.<br>
<br>
To do client TLS or message signing, need to stick a client.crt and
client.key into src/main/resources (Those are .gitignored.)<br>
<br>
Most of the SOAP code itself is in the AbstractSOAPClientTest base
class. But the real thing to pay attention to is the Spring wiring
and what beans are used and how they they fit together. I put a lot
of comments into the Spring XML files. Especially take note of the
HttpClient and enhanced TLS stuff, and also the way the message
pipeline is obtained from a factory injected into the SOAP client
impl. <br>
<br>
On the latter: I illustrate a couple of fundamental ways to do that,
using Spring machinery which I don't recall us using before: 1)
lookup method injection 2) ServiceLocatorFactoryBean. You can read
the comments there and let me know if it's not clear what is going
on.... The ServiceLocatorFactoryBean technique in particular is
pretty cool, I think. Could be useful elsewhere.<br>
<br>
For a unit test, etc, you could also skip all that and just create a
concrete impl extending AbstractPipelineHttpSOAPClient and
overriding the abstract method newPipeline(). I've done that for
quick and dirty testing with an inline class. The equivalent of
what you see in the Spring wiring would be something like this:<br>
<br>
<tt>AbstractPipelineHttpSOAPClient<SAMLObject, SAMLObject>
soapClient = new AbstractPipelineHttpSOAPClient() {</tt><tt><br>
</tt><tt> protected HttpClientMessagePipeline newPipeline()
throws SOAPException {</tt><tt><br>
</tt><tt> BasicHttpClientMessagePipeline pipeline = new
BasicHttpClientMessagePipeline(</tt><tt><br>
</tt><tt> new HttpClientRequestSOAP11Encoder(),</tt><tt><br>
</tt><tt> new HttpClientResponseSOAP11Decoder()</tt><tt><br>
</tt><tt> );</tt><tt><br>
</tt><tt> BasicMessageHandlerChain<SAMLObject>
outboundPayloadHandler = new
BasicMessageHandlerChain<SAMLObject>();</tt><tt><br>
</tt><tt>
outboundPayloadHandler.setHandlers(Lists.<MessageHandler<SAMLObject>>newArrayList(</tt><tt><br>
</tt><tt> new
SAMLOutboundProtocolMessageSigningHandler()));</tt><tt><br>
</tt><tt>
pipeline.setOutboundPayloadHandler(outboundPayloadHandler);</tt><tt><br>
</tt><tt> return pipeline;</tt><tt> </tt><tt><br>
</tt><tt> }};</tt><tt><br>
</tt><tt><br>
</tt><tt>soapClient.setHttpClient(httpClient);</tt><tt><br>
</tt><br>
<br>
<br>
But I wouldn't imagine we would do that in the IdP, we'd use wired
beans. Esp. since we might want to have multiple pipeline
strategies (with different handlers, e.g. artifact resolution vs
logout), with the one to use possibly determined dynamically at
runtime by the pipeline name strategy plugin on
PipelineFactoryHttpSOAPClient. That's the concrete SOAPClient impl.<br>
</body>
</html>