5

We are using OpenSAML on the Service Provider Site to provide SSO for our clients. Our client(ID Provider) is using OpenSSO on their end. The SAML Response being posted by OpenSSO is a little different when it comes to the signature element in that it is not qualified by the namespace. This doesn't seem to go down well with OpenSAML and it returns a null from the samlResponse.getSignature() method, due to which I cannot validate the signature.

Signature Snippet of the SamlReponse that is causing the issue

<Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <SignedInfo>
        <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <Reference URI="#s2d10cccbd58d1f78c2c76c74c82a236548c929ffd">
            <Transforms>
                <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </Transforms>
            <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <DigestValue>j+KBoDOtEcyCquPTxRCXoBulStQ=</DigestValue>
        </Reference>
    </SignedInfo>
    <SignatureValue>Dv+owuZfGFymGGrw2gHA3/7GVC6mXt8JMW+tOvmtnjTRJZaDE+Nb2NCngio1Tnqu4LWnvVrry4Wk... 6QcIJi/kGc4YFMSQj/Q=</SignatureValue>
    <KeyInfo>
        <X509Data>
            <X509Certificate>MIIEhDCCA+2gAwIBAgIQXxhipi2wpPxWi7MTVfFVHDANBgkqhkiG9w0BAQUFADCBujEfMB0GA1UE... 78Q/lRQuBhHMy02lKctnwjBeEYA=</X509Certificate>
        </X509Data>
    </KeyInfo>
</Signature>

Signature snippet from another SAML Response that works

<dsig:Signature xmlns="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
    <dsig:SignedInfo>
        <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
        <dsig:Reference URI="#id-TtLltjcBSOAJ6OipumUEj8o0Qag-">
            <dsig:Transforms>
                <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            </dsig:Transforms>
            <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
            <dsig:DigestValue>5c95zhA139qzMvZA2A445F3LWaU=</dsig:DigestValue>
        </dsig:Reference>
    </dsig:SignedInfo>
    <dsig:SignatureValue>JsmRFJn1CjClHs4rf0hrwKzOq6ZtmnOEm/PNiaJvYurko/ZP+PApWhk55x0unIVwZ6XDv3k8Dj81WqUl07J0Dkvzp71bccIgiGTRzoNPT71nBAXxJmZiXz51JWctg13zjxP0oQMSpWytKCrFkCkJ0So3RQl3WixYV3miK0YjJnM=</dsig:SignatureValue>
    <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    </ds:KeyInfo>
</dsig:Signature>

As you can see above the signature snippet from the OpenSSO server does not contain the namespace qualifier as specified in the SAML Bindings spec.

The last option for me would be to do some massaging of the SAMLResponse that is posted to prepend the namespace to the signature elements to make the OpenSAML libraries work.

Any ideas on how to solve this using the OpenSAML libraries highly appreciated.

Thanks in advance CJ

Doug Porter
  • 7,721
  • 4
  • 40
  • 55
user464336
  • 51
  • 1
  • 5

2 Answers2

0

We are using the ComponentSpace SAML 2.0 library and ran into a similar issue with a customer that was using ADFS as their Identity Provider. The XML elements generated by their ADFS server were not individually qualified as with your first example and I initially thought that was the issue.

Turns out it is valid XML and was not the issue. In our case the ComponentSpace library had different methods to handle signed assertions vs non-signed assertions. Once we switched to checking for signed assertions it worked.

The OpenSAML library should be able to handle non-qualified XML elements. You may want to report that as an issue to the library maintainers.

Brad Patton
  • 4,007
  • 4
  • 34
  • 44
0

You might be able to do some DOM manipulation to repair the XML. For instance, here's some code I had to write to fix some namespace attributes in SAML Response XML from a client (actually, it was that the namespaces were defined at Response element but Assertion needed to be extracted and needed the namespaces retained).

Element assertionElem = assertion.getDOM();

if (!assertionElem.hasAttribute("xmlns:saml")) {
   assertionElem.setAttribute("xmlns:saml", "urn:oasis:names:tc:SAML:2.0:assertion");
}

if (!assertionElem.hasAttribute("xmlns:ds")) {
   assertionElem.setAttribute("xmlns:ds", "http://www.w3.org/2000/09/xmldsig#");
}

String assertionXml = Serializer.serializeXml(assertionElem, true, true);

It's possible you could just add the xmlns="http://www.w3.org/2000/09/xmldsig#" attribute to Signature, then setDOM() to update. The question is, whether samlResponse.getSignature().getDOM() will get you the XML, or whether you'll have to get the DOM for the whole response and extract the Signature element from that.

Of course, really, the client shouldn't be sending you improperly namespaced XML, but we know how that goes.

Doug Porter
  • 7,721
  • 4
  • 40
  • 55
JST
  • 1,154
  • 6
  • 15