possible to remove namespace in <ds:Signature>?

[adamw...@elearning247.com]

We're having a problem working out an issue with a client IdP. Their response contains a signature within a <Signature> tag, without the "ds" namespace.
We are getting the error "SimpleSAML_Error_Exception: Neither the assertion nor the response was signed."
From my understanding this can be caused by a missing signature in the response.
Comparing the assertion and the response, the assertion from our SP contains <ds:Signature> but their response contains <Signature>. They have told us that they cannot change the way the signature is provided in the response as it would break other SPs they are using.

So I'm wondering if its at all possible to change the expected schema to get this working?

Thank you

[Peter Schober]

* adamw...@elearning247.com <adamw...@elearning247.com> [2014-11-13 13:18]:

> We're having a problem working out an issue with a client IdP. Their
> response contains a signature within a <Signature> tag, without the "ds"
> namespace.

Usually namespaces are red herrings. But from the lack of detail in
your description this could mean anything, i.e. be valid or not.

> We are getting the error "SimpleSAML_Error_Exception: Neither the assertion
> nor the response was signed."
> From my understanding this can be caused by a missing signature in the
> response.

Not the response and not the assertion, as the message clearly states.

> Comparing the assertion and the response, the assertion from our SP
> contains <ds:Signature> but their response contains <Signature>. They have
> told us that they cannot change the way the signature is provided in the
> response as it would break other SPs they are using.

Breaking this one or that one is a stupid game to be in. Luckily
there's only a handful ways that are /correct/ and this can be
determined beyond speculation, e.g. by learning about XML and
namespaces.
If their software in fact is broken and they won't fix it, well,
you're screwed then, short of hacking the code yourself to allow to
accepting invalid and broken stuff, thereby probably opening up your
system to all kinds of security issues.
-peter

[Adam Wilson]

OK thanks, for clarity, here is the request and following response with sensitive data changed:

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    ID="_9f0b864d047b7c95f541f0caeb519729f8526b288d"
                    Version="2.0"
                    IssueInstant="2014-11-04T12:17:01Z"
                    Destination="http://test.idp.com/Idp/Index"
                    AssertionConsumerServiceURL="http://test.sp.com/simplesaml/module.php/saml/sp/saml2-acs.php/test-sp"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    >
    <saml:Issuer>https://test.sp.com/simplesaml/module.php/saml/sp/metadata.php/test-sp</saml:Issuer>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
                        AllowCreate="true"
                        />
</samlp:AuthnRequest>

<saml2p:Response Destination="https://test.sp.com/simplesaml/module.php/saml/sp/saml2-acs.php/test-sp"
                 ID="id0906dd7c36094a9c9db7c828caed7c28"
                 Version="2.0"
                 IssueInstant="2014-11-04T12:17:38Z"
                 xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol"
                 >
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">Logic.Idp</saml2:Issuer>
    <saml2p:Status>
        <saml2p:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
    </saml2p:Status>
    <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
                     Version="2.0"
                     ID="_246cbc10-8595-420a-8357-0f9f46d05e34"
                     IssueInstant="2014-11-04T12:17:38Z"
                     >
        <saml2:Issuer>Logic.Idp</saml2:Issuer>
        <saml2:Subject>
            <saml2:NameID>test...@test.sp.com</saml2:NameID>
            <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer" />
        </saml2:Subject>
        <saml2:Conditions NotOnOrAfter="2014-11-04T12:19:38Z" />
    </saml2:Assertion>
    <Signature xmlns="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="#id0906dd7c36094a9c9db7c828caed7c28">
                <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>IW8CMuN9V2Hs27mlgNG7z2FAIxw=</DigestValue>
            </Reference>
        </SignedInfo>
        <SignatureValue>F1BslUaiHERE+KFTjD0JXlpT3bUbN38UD2l0ovlN22dArZjdq1bGnc9MiWekAvsGvv0KNjOzw0BBQdQfuulQJpk2b5zdS/PeiO/j5kp9Rt+oyKlAc5gUW9y8OAM7QXEM5V84zLmWjyZTRX/cqIlPvFIErEVzq/NRz2nBbfKPsd8=</SignatureValue>
    </Signature>
</saml2p:Response>

--
You received this message because you are subscribed to a topic in the Google Groups "simpleSAMLphp" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/simplesamlphp/qiHfW5NI0mE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to simplesamlph...@googlegroups.com.
To post to this group, send email to simple...@googlegroups.com.
Visit this group at http://groups.google.com/group/simplesamlphp.
For more options, visit https://groups.google.com/d/optout.

[Peter Schober]

* Adam Wilson <adamw...@elearning247.com> [2014-11-13 13:50]:
> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

The Signature XML element has a namespace definition in an XML
attribute, so that's all fine. I.e., the red herring I mentioned.
-peter

[Adam Wilson]

Ok thats great thanks.

Is there anything else I can look for to explain the error message? Missing signature in the request?

[Peter Schober]

* Adam Wilson <adamw...@elearning247.com> [2014-11-13 15:17]:

> Is there anything else I can look for to explain the error message?
> Missing signature in the request?

I think the Signature element needs to be a child element of the
Assertion element, not a sibling.
-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2014-11-13 15:22]:

> I think the Signature element needs to be a child element of the
> Assertion element, not a sibling.

Nah, it references the ID attribute of the Response element.
I'll spare you further guesswork.
You (or rather they) can ask at saml...@lists.oasis-open.org for
definitive statements.
-peter

[Peter Schober]

* Peter Schober <peter....@univie.ac.at> [2014-11-13 15:39]:

> * Peter Schober <peter....@univie.ac.at> [2014-11-13 15:22]:
> > I think the Signature element needs to be a child element of the
> > Assertion element, not a sibling.
>
> Nah, it references the ID attribute of the Response element.

I'm pretty sure their Response is schema-invalid. Looking at the XSD
the Response (like the Assertion) is defined to be a sequence (i.e.,
order matters) of an Issuer, then an optional Signature.
In the XML you posted the first child element of the Response is the
Issuer (OK), but then the Status, the Assertion and only then the
Signature element. Cf. SAML Core 3.2.2 seems,
-peter

[Adam Wilson]

Thanks for all the info very useful.
Comparing to a successful exchange from another IdP we have using our SP, I can see that the successful response has the signature within the Assertion tag, not as a sibling, as you suggest. I will see if they can adjust their XML structure.

The SAML 2.0 core doc seem to suggest this: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf (page 66)

[Peter Schober]

* Adam Wilson <adamw...@elearning247.com> [2014-11-13 16:06]:

> Comparing to a successful exchange from another IdP we have using
> our SP, I can see that the successful response has the signature
> within the Assertion tag, not as a sibling, as you suggest. I will
> see if they can adjust their XML structure.

Not quite (my mistake, earlier): From the Reference/@ID of the
Signature it's clear the Signature element is supposed to be the
Response's, not the Assertion's.
So the mistake (if I'm correct in all that; I may not be) would be to
place the Response's Signature not immediately after the Issuer
element (the first child of the Response).
-peter

[adamw...@elearning247.com]

OK, the plot thickens, after making suggestions regarding the Response XML I have got this back from the client:

Section 5.3 of http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf states on line 2889 that “When a SAML assertion does not contain a <ds:Signature> element, but is contained in an enclosing SAML element that contains a <ds:Signature> element, and the signature applies to the <Assertion> element and all its children the assertion can be considered to inherit the signature from the enclosing element”. Our approach means that the signature applies to the entire document therefore the Assertion element inherits the signature.
 
With regards to the point about the order of the elements, whilst the spec suggests that the <ds:signature> element should come immediately after the <issuer> node, please can you advise on how you are validating the XML, as the elements are still at the same level within the hierarchy so order should not really effect the process unless specific validation steps are being made.
Since changing the code base would have a knock on effect to a series of integration points, understanding this will allow us to look further into what changes may need to be made.

Without pouring through the SimpleSAML code, its difficult for me to answer these questions.  Would anyone here be kind enough to offer some help on how SimpleSAMLPHP validates the XML in the Response?

Thank you

[Peter Schober]

* adamw...@elearning247.com <adamw...@elearning247.com> [2014-11-17 15:49]:

> I have got this back from the client:
>
> Section 5.3 of
> > http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf states
> > on line 2889 that “When a SAML assertion does not contain a <ds:Signature>
> > element, but is contained in an enclosing SAML element that contains a
> > <ds:Signature> element, and the signature applies to the <Assertion>
> > element and all its children the assertion can be considered to inherit the
> > signature from the enclosing element”. Our approach means that the
> > signature applies to the entire document therefore the Assertion element
> > inherits the signature.
> >
> > With regards to the point about the order of the elements, whilst the spec
> > suggests that the <ds:signature> element should come immediately after the
> > <issuer> node, please can you advise on how you are validating the XML, as
> > the elements are still at the same level within the hierarchy so order
> > should not really effect the process unless specific validation steps are
> > being made.
> > Since changing the code base would have a knock on effect to a series of
> > integration points, understanding this will allow us to look further into
> > what changes may need to be made.

They should seek guidance from the OASIS SSTC, as I said before:

* Peter Schober <peter....@univie.ac.at> [2014-11-13 15:39]:

> You (or rather they) can ask at saml...@lists.oasis-open.org for
> definitive statements.

Not sure what's so hard about sending an email there instead of here.

If they think SSP is in violation of the SAML specs they or you can
open an issue in the SSP issue tracker. If this is not about SSP, but
their software, then see above (i.e., not an issue for this list).
-peter

[Jaime Pérez Crespo]

Hi Adam,

Peter is right, you should ask the OASIS SSTC for a normative answer. In any case, it seems pretty clear that the problem here is the order of the elements. In XML Schema, a sequence is an *ordered* list of elements, as you can see in section 2.2.3.1 (Model Group) of (1). In SAML, a Response is a complex type that contains a sequence of elements (as defined by XML Schema), defined as:


<complexType name="StatusResponseType">
<sequence>

<element ref="saml:Issuer" minOccurs="0"/>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="samlp:Extensions" minOccurs="0"/>
<element ref="samlp:Status"/>

</sequence>
<attribute name="ID" type="ID" use="required"/>
<attribute name="InResponseTo" type="NCName" use="optional"/>
<attribute name="Version" type="string" use="required"/>
<attribute name="IssueInstant" type="dateTime" use="required"/>
<attribute name="Destination" type="anyURI" use="optional"/>
<attribute name="Consent" type="anyURI" use="optional"/>

</complexType>

As you can see, the signature must appear before any children of the response type *except* the Issuer, which is optional. So to me it is pretty clear that the example response from your second message is wrong, as the Signature element should appear immediately after the Issuer element.

(1) http://www.w3.org/TR/xmlschema-1/

> --
> You received this message because you are subscribed to the Google Groups "simpleSAMLphp" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to simplesamlph...@googlegroups.com.

> To post to this group, send email to simple...@googlegroups.com.
> Visit this group at http://groups.google.com/group/simplesamlphp.
> For more options, visit https://groups.google.com/d/optout.

--
Jaime Pérez
UNINETT / Feide
mail: jaime...@uninett.no
xmpp: ja...@jabber.uninett.no

"Two roads diverged in a wood, and I, I took the one less traveled by, and that has made all the difference."
- Robert Frost