unsigned authN requests

[David Bantz]

I have a vendor that is currently sending unsigned authN requests [having persuaded them to remove an errant X.509 certificate embedded in the request].  My IdP objects that the unsigned request does not meet security requirements (refusing to process it).  As this is a service providing electronic signatures for work flow and approval documents, it has seemed to me reasonable and prudent to ask that they digitally sign the authN request to our IdP.  

* Am I off base in asking for signed authN request?  Isn't that usual?

* If they are unable or unwilling [sic!] to sign the SAML authN request, I presume I can configure my IdP to permit unsigned requests from them, but I haven't discovered the documentation for doing so.  

* Is an exception or override set in relying-party.xml configuration for that SP?

* Do you have a suggested strategy/rationale to persuade my vendors to sign requests?

* Is this snippet from the "do not edit" portion of the distribution of relying-party.xml where the default requirement is set?

    <security:SecurityPolicy id="shibboleth.SAML2SSOSecurityPolicy" xsi:type="security:SecurityPolicyType">
        <security:Rule xsi:type="samlsec:Replay"/>
        <security:Rule xsi:type="samlsec:IssueInstant"/>
        <security:Rule xsi:type="samlsec:SAML2AuthnRequestsSigned"/>
        <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" />
        <security:Rule xsi:type="security:ClientCertAuth" trustEngineRef="shibboleth.CredentialTrustEngine" />
        <security:Rule xsi:type="samlsec:MandatoryIssuer"/>
    </security:SecurityPolicy>


Thanks,

David Bantz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20130605/b49a371e/attachment.html