Sending SOAP messages in OpenSAML v3

[Stefan Rasmusson]

I love the new handlers, Im
using SAMLOutboundProtocolMessageSigningHandler to sign SOAP. Is there
anyone for validating on the other side? I could not find a obvious
candidate.

The validateJCEProviders and validateNonSunJAXP, are they gone?

Also I couldn't seem to find the AbstractPipelineHttpSOAPClient in the
3.1.1 version so I using the 3.3.0-SNAPSHOT. What is the ETA on releasing
3.3.0?

--
Stefan

On Thu, Apr 28, 2016 at 8:48 AM, Brent Putman <putmanb at georgetown.edu>
wrote:

>
>
> On 4/28/16 2:11 AM, Stefan Rasmusson wrote:
>
> Hi Brent
> Thanks for answering and thanks for the information.
> I have started experimenting and I am getting somewhere. I have managed to
> send a SOAP message, recieved it, sent a response. But when Im trying to
> recieve the response, I get nothing. I know that the respons is being sent
> because if I disable the response encoder I get "Premature end of file" at
> the reciever.
>
> Any ideas what I'm doing wrong?
>
>
> Yes, based on the code you included I think you're not looking at the
> correct inbound MessageContext.  When you create the InOutOperationContext,
> use a null value for the inbound one.  That's because it is actually
> *created* by the response decoder.  So it won't be populated on the
> InOutOperationContext until after the call returns.  So at the end try
> instead like:
> System.out.println(context.getInboundMessageContext().getMessage()).
>
> By the way is the code I have put together the correct way of using the
> pipeline and encoder etc? I based it on a example you gave in a earlier
> mailing list conversation, it was refered to as the "quick and dirty way"
> =).
>
>
> Yes, creating an inline class from the abstract one is an easy way to get
> a concrete impl for simple use cases.  The more sophisticated way is to use
> the PipelineFactory- one, which allows to support multiple named pipelines
> for different cases (with different inbound and outbound handlers, etc).
> If you're using Spring, there's a slick way to use a
> ServiceLocatorFactoryBean to have it dynamically create the factory backed
> by Spring beans.
>
> Also, I forgot that there are actually SAML-specific impls of the client
> encoder and decoder.  On the decoder I think the main win is it allows to
> get a SAMLObject as the decoded inbound message, rather than an Envelope.
> That allows for more "payload-oriented" messaging style, like that other
> SAML messaging components.
>
>
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20160430/4cde01e9/attachment.html>