unsigned authN requests

[Brent Putman]

(Sent to me directly, taking back to the users list).


On 6/6/13 3:06 AM, David Bantz wrote:
> Holy Cow.  Thanks for this.  I confess I didn't know that was an option, but it makes some sense.
>
> Here's the decoded incoming SAML request:
>
> 17:39:08.233 - DEBUG [PROTOCOL_MESSAGE:113] - 
> <?xml version="1.0" encoding="UTF-8"?><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="https://demo.docusign.net/SAML/" Destination="https://idp.alaska.edu/idp/profile/SAML2/Redirect/SSO" ForceAuthn="false" ID="_dde46841-b526-45cf-af2d-4578cefae706" IsPassive="false" IssueInstant="2013-06-06T01:39:07.044Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Version="2.0">
>    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://demo.docusign.net</saml:Issuer>
>    <samlp:NameIDPolicy AllowCreate="true"/>
> </samlp:AuthnRequest>
>
> No signature in the XML as you indicate.


Ok, as expected.


>
> But I was misled, and remain confused by this a few lines later:
>
> 17:39:08.246 - DEBUG [org.opensaml.saml2.metadata.provider.AbstractMetadataProvider:518] - Searching for entity descriptor with an entity ID of https://demo.docusign.net
> 17:39:08.246 - DEBUG [org.opensaml.security.MetadataCredentialResolver:348] - Added new credential collection to cache with key: [https://demo.docusign.net,{urn:oasis:names:tc:SAML:2.0:metadata}SPSSODescriptor,urn:oasis:names:tc:SAML:2.0:protocol,SIGNING]
>
> seeming to indicate the IdP is using the certificate from the SP metadata to check the signature.  


Yes, but as I mentioned it must be signed with a non-XML signature.  If
the data in the AuthnRequest is to be believed, they delivered it to
your HTTP-Redirect binding endpoint, so it must be carrying that form of
binding level signature.  If you can capture the request from the SP
into the IdP with LiveHeaders, SAMLTracer, etc, you should see that the
request contains, in addition to the SAMLRequest param, a Signature param.

>
> Do I understand that the IdP, not finding an XML signature in the authN request has then gone on to check a signature in the original https redirect?
> Seems odd - out of order at least, but it seems I'm pretty confused.

It actually just checks every type of signature that is present.  The
actual order of the checks comes from the list of security policy rules
you earlier posted, in particular these three:


<security:Rule xsi:type="samlsec:ProtocolWithXMLSignature"
trustEngineRef="shibboleth.SignatureTrustEngine" />
<security:Rule xsi:type="samlsec:SAML2HTTPRedirectSimpleSign"
trustEngineRef="shibboleth.SignatureTrustEngine" />
<security:Rule xsi:type="samlsec:SAML2HTTPPostSimpleSign"
trustEngineRef="shibboleth.SignatureTrustEngine" />



Those are in practice mutually exclusive, so the ordering is a bit
arbitrary.

--Brent