Stupid CAS Saml11TicketValidator Parsing Issue

[Brent Putman]

On 11/12/15 10:57 AM, Cantor, Scott wrote:
> On 11/12/15, 9:31 AM, "dev on behalf of Marvin Addison" <dev-bounces at shibboleth.net on behalf of marvin.addison at gmail.com> wrote:
>
>
>
>> The parse issue discussed in a recent users thread [1] is really biting us hard at Virginia Tech. Spring Security versions as recent at 3.2.5.RELEASE are affected, and we have lots of SS integrations here. That has prompted research into adding a configuration option to force the SOAP envelope namespace prefix to be what the CAS client expects, SOAP-ENV. I did some recon, but simply don't see a way to control that. Can one of our OpenSAML experts point me in the right direction to investigate further?
> IIRC when you use an XMLObjectBuilder, there's a buildObject variant to specify the entire element, including the prefix.

Yes.  I just tested it out to make sure that it works as intended.  Be
aware that you do have to specify the custom prefix on *all* the
affected elements, e.g. both the Envelope and Body (and Header if you
have that). 

Something like this should work (or you can use builder instances
directly instead of using the XMLObjectSupport method.

    String customPrefix = "SOAP-ENV";
    QName envelopeName = new QName(SOAPConstants.SOAP11_NS,
Envelope.DEFAULT_ELEMENT_LOCAL_NAME, customPrefix);
    QName bodyName = new QName(SOAPConstants.SOAP11_NS,
Body.DEFAULT_ELEMENT_LOCAL_NAME, customPrefix);
       
    Envelope envelope = (Envelope)
XMLObjectSupport.buildXMLObject(envelopeName);
    envelope.setBody((Body) XMLObjectSupport.buildXMLObject(bodyName));


We consciously don't expose XML namespace prefixes as a directly
configurable option in the library, because code (like the stuff in
question here) that can't deal with with arbitrary prefixes is just
broken, and we're not going to complicate the library for something
that is, or should be, a non-problem.

But regarding this, just curious:  I thought this was fixed in newer
versions of the CAS client, and the workaround was just dropping in a
newer version of the CAS client jar.  B/c Walter said in the original
thread:

>
> I ran in to this problem with a couple of applications.  In every
> case, it was easily
> solved by updating the "CAS Client for Java" jar to a recent version.


... and others said they did that and it worked fine for them.  Do I
infer that is not possible in all cases?  IMHO it's preferable to fix
the broken software than the other way around.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20151112/1f0df0ca/attachment.html>