Does SP3 not sign authn requests by default?

[Wessel, Keith]

All,

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="urn:mace:incommon:uiuc.edu"
                            discoveryProtocol="SAMLDS" signing="true" discoveryURL="">
                            SAML2 SAML1
                        </SSO>

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?

Keith


-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Cantor, Scott
Sent: Sunday, July 22, 2018 11:26 AM
To: Shib Users <users at shibboleth.net>
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 shibboleth.net on behalf of kwessel at illinois.edu> 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 https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net