Missing SOAP header in ECP response

[Mitu Singh]

Brent, I will try to implement the workaround that you have suggested. It would be great if you send an update when this issue is resolved.

And thanks for the help on how to set up the debugging for the protocol message. I will try that too.

Thanks!




________________________________
 From: Brent Putman <putmanb at georgetown.edu>
To: dev at shibboleth.net 
Sent: Wednesday, December 12, 2012 9:06 PM
Subject: Re: Missing SOAP header in ECP response
 




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/20121213/2f98c388/attachment.html