Does SP3 not sign authn requests by default?

Wessel, Keith kwessel at
Wed Jul 25 16:59:42 EDT 2018


The SP admin restored a pre-upgrade version of their service, and it worked without signing="true" in the ApplicationDefaults element. Digging deeper, they saw that they had added it back in 2.5 or 2.6 to the <SSO> element:

<SSO entityID=""
                            discoveryProtocol="SAMLDS" signing="true" discoveryURL="">
                            SAML2 SAML1

This was still there after the upgrade to 3.0 but didn't result in the authn request to the IdP being signed. The signing attribute had to be added to the <ApplicationDefaults> elemnt before the IdP would skip endpoint validation again, or so it appears.

I believe their system was running 3.0.0, not 3.0.1, when this broke, but I don't see anything that seems relevant in the issues addressed in 3.0.1.

Was this an intended change in behavior? Mores specifically, what should happen when signing="true" in the <SSO> block?


-----Original Message-----
From: users <users-bounces at> On Behalf Of Cantor, Scott
Sent: Sunday, July 22, 2018 11:26 AM
To: Shib Users <users at>
Subject: Re: Does SP3 not sign authn requests by default?

On 7/20/18, 6:19 PM, "users on behalf of Wessel, Keith" <users-bounces at on behalf of kwessel at> wrote:

> FWIW, adding signing="true" to our ApplicationDefaults has fixed the issue. The docs say that this should behave the 
> same as 2.6 did: our IdP metadata says nothing about wantRequestsSigned, and I read the docs as it'll be signed unless 
> the metadata specifically says not to as long as the SP is able to sign it. Do I misunderstand the "soft false" discussed in 
> the SP 3 signing and encryption docs?

I missed this bit when I just responded, I assumed you were using metadata as a signal. Without that, there's no way this would have worked before. The SP, as Peter said, has never signed by default. It used to just be a true/false setting and defaulted to false.

In 2.6 it got more complicated, but it still generally did not sign AuthnRequests in particular unless set to true, or if it was left as "conditional", the SP looks at the metadata to decide the default.

I don't believe this has changed in 3.0, but in your scenario I think you have to determine what they really were doing before to know what's going on. I can debug it a little and verify how it runs, but I can't prove anything about a configuration that isn't really known.

-- Scott

For Consortium Member technical support, see
To unsubscribe from this list send an email to users-unsubscribe at

More information about the users mailing list