Missing SOAP header in ECP response

[Mitu Singh]

Brent, Using org.opensaml.ws.soap.soap11.encoder.http.HTTPSOAPEncoder, I can generate a valid SOAP Envelope with header. I will have to do more testing with ECP client and SP to make sure everything works. Thanks!

And thanks for the pointer about the Protocol Message loggingl. I can see the messages in the log file!


On Dec 12, 2012, at 9:06 PM, Brent Putman <putmanb at georgetown.edu> wrote:

> 
> 
> On 12/12/12 6:13 PM, Mitu Singh wrote:
>> Thanks Brent. It would be great help if you could look into the code to see if I need to change something. 
> 
> Ok, I think I know what the issue is.  The problem isn't the code that's constructing the Envelope, etc, it's the encoder that you are using.  The SAML 2 binding version of HTTPSOAP11Encoder (meaning org.opensaml.saml2.binding.encoding.HTTPSOAP11Encoder) essentially doesn't currently allow using SOAP headers, because it indiscriminately ignores any SOAP Envelope that you set in the message context and instead builds its own.  IIRC someone else pointed this out once and I actually thought we had fixed that, but     apparently not.  I'll look at doing that.
> 
> In the meantime, just try switching to the java-openws impl of HTTPSOAP11Encoder which is org.opensaml.ws.soap.soap11.encoder.http.HTTPSOAP11Encoder.  It respects the presence of a pre-existing SOAP Envelope in the message context's outbound message slot.  I believe the only functional difference between them for your purposes is going to be that the SAML version sets the HTTP SOAPAction header to "http://www.oasis-open.org/committees/security", which is a MAY in the SAML 2 bindings spec.  The openws one sets it to an empty string, unless there is a WS-Addressing Action header set on the Envelope, in which case it pulls the action value from that.
> 
> In terms of code compatibility, the main difference is going to be that the openws one does not implement the SAMLMessageEncoder interface, so it doesn't expose the binding URI.
> 
> If either or both of those things is important for your purposes, you could just trivially subclass the openws one and make it do those 2 things. 
> 
> The biggest difference is that the openws is an impl of HandlerChainAware, which is a concept that was introduced after the SAML ones in java-opensaml2 were written.  They were never backported to support that stuff, and probably won't be.
> 
>> 
>> Also, before the message is sent I would like to output the message (envelope with header,body and the saml response) to the console. How can I achieve this? I can output just the saml response using:
>>          ResponseMarshaller marshaller = new ResponseMarshaller();
>>         Element plaintextElement = marshaller.marshall(samlResponse);
>>         String responseString = XMLHelper.nodeToString(plaintextElement);
>>         System.out.println("SAML response: " + responseString);
>> 
>> Can I do something similar to output the entire message?
> 
> 
> Yes, the message encoder and decoder impls already have this support built-in via special logging categories.  Just turn on DEBUG level     logging for Logger with name "PROTOCOL_MESSAGE" and you will get whatever is in the message context as the outbound or inbound message respectively.  To get logging to the console or anywhere else you want, you just need to supply you desired logging impl of SLF4J (e.g logback or one of the slf4j-to-whatever adapters) and the appropriate configuration.
> 
>  
> 
> 
> --
> 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/20121215/b36014cb/attachment.html