Does SP3 not sign authn requests by default?

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Does SP3 not sign authn requests by default?

Wessel, Keith William
We have a multi-domain SP hosting a number of CPanel sites. It automatically pulled in SP 3.0 (they clearly need to fix how the prod environment gets updated), and now they're having authentication problems. It's one of the few SPs for which we've allowed the skip endpoint validation if signed option in the IdP.

Before, the authn requests were signed, and everything was working with the endpoint validation checks being skipped. Is this no longer the default in SP V3? And if not, how do we turn it back on?

Thanks,
Keith

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Wessel, Keith William
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?

Thanks,
Keith


-----Original Message-----
From: Wessel, Keith
Sent: Friday, July 20, 2018 4:32 PM
To: [hidden email]
Subject: Does SP3 not sign authn requests by default?

We have a multi-domain SP hosting a number of CPanel sites. It automatically pulled in SP 3.0 (they clearly need to fix how the prod environment gets updated), and now they're having authentication problems. It's one of the few SPs for which we've allowed the skip endpoint validation if signed option in the IdP.

Before, the authn requests were signed, and everything was working with the endpoint validation checks being skipped. Is this no longer the default in SP V3? And if not, how do we turn it back on?

Thanks,
Keith

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Michael A Grady

On Jul 20, 2018, at 5:19 PM, Wessel, Keith <[hidden email]> 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 haven't looked at the SP 3 docs, but 2.x never signed by default. That's stated explicitly here:


--
Michael A. Grady
IAM Architect, Unicon, Inc.




--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

signature.asc (891 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Peter Schober
In reply to this post by Wessel, Keith William
* Wessel, Keith <[hidden email]> [2018-07-20 23:32]:
> Before, the authn requests were signed, and everything was working
> with the endpoint validation checks being skipped. Is this no longer
> the default in SP V3?

The SP never signed its authn requests by default.

> And if not, how do we turn it back on?

New SP v3 documentation:
https://wiki.shibboleth.net/confluence/display/SP3/

-> Configuration:
https://wiki.shibboleth.net/confluence/display/SP3/Configuration

-> Signing and Encryption
https://wiki.shibboleth.net/confluence/display/SP3/SigningEncryption

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Peter Schober
In reply to this post by Wessel, Keith William
* Wessel, Keith <[hidden email]> [2018-07-21 00:20]:
> 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?

That's not what the docs say to me.

  The default value [...] defaults to false (with a caveat) for SAML 2.0
  SSO initiation. The caveat with SAML 2.0 authentication is that
  omitting the setting defaults to a softer false that really means
  "don't sign unless the IdP's metadata includes the
  WantAuthnRequestsSigned flag and the SP can do so".

I wouldn't know to paraphrase the quoted last sentence to make this
more clear. "Don't sign unless the IDP metadata says otherwise"
combined with your IDP metadata not saying otherwise should and does
lead to "don't sign", no?
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Wessel, Keith William
Thanks, Mike and Peter. Peter, your paraphrasing of the docs help.

So, now the question is why did this ever work in 2.6? The SP admins don't recall ever setting signing="true" before yesterday afternoon, yet their multiple hostnames don't all have published endpoints in metadata and were being permitted by our IdP. So, I think it's safe to assume that endpoint validation was being skipped, and thus there had to be some signing going on. I'm also assuming that nothing in shibboleth2.xml would have been automatically updated upon installation of the SP 3.0 RPM that might have somehow removed a setting for signing that the SP admins forgot they had made for 2.6.

It seems that adding signing="true" is a good fix, and not just a band aid, in 3.0. But it'd make me feel better if I could explain why this worked in 2.6 without that.

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Saturday, July 21, 2018 4:59 AM
To: [hidden email]
Subject: Re: Does SP3 not sign authn requests by default?

* Wessel, Keith <[hidden email]> [2018-07-21 00:20]:
> 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?

That's not what the docs say to me.

  The default value [...] defaults to false (with a caveat) for SAML 2.0
  SSO initiation. The caveat with SAML 2.0 authentication is that
  omitting the setting defaults to a softer false that really means
  "don't sign unless the IdP's metadata includes the
  WantAuthnRequestsSigned flag and the SP can do so".

I wouldn't know to paraphrase the quoted last sentence to make this
more clear. "Don't sign unless the IDP metadata says otherwise"
combined with your IDP metadata not saying otherwise should and does
lead to "don't sign", no?
-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Peter Schober
* Wessel, Keith <[hidden email]> [2018-07-21 15:22]:
> It seems that adding signing="true" is a good fix, and not just a
> band aid, in 3.0. But it'd make me feel better if I could explain
> why this worked in 2.6 without that.

Then restore an old copy (or all available copies) of shibboleth2.xml
from backup (or version control) and check for signing settings.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Wessel, Keith William
Well, obviously, yes. But since the SP admins didn't even seem to know about signing="true", I doubt they made this change. I could be wrong, though, and they could have forgotten. I've asked them to restore shibboleth2.xml from backups on Monday to see if it had explicit signing settings. An explicit signing setting is the only thing that would make sense, but if it is in the old shibboleth2.xml, that would also imply that the upgrade to 3.0 removed it, and I hope that the RPM wouldn't make that kind of modification to the configuration.

I'll also test the endpoint validation skipping on my SP sandbox on Monday which is still running 2.6.

If I learn anything interesting, I'll report back.

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Saturday, July 21, 2018 9:34 AM
To: [hidden email]
Subject: Re: Does SP3 not sign authn requests by default?

* Wessel, Keith <[hidden email]> [2018-07-21 15:22]:
> It seems that adding signing="true" is a good fix, and not just a band
> aid, in 3.0. But it'd make me feel better if I could explain why this
> worked in 2.6 without that.

Then restore an old copy (or all available copies) of shibboleth2.xml from backup (or version control) and check for signing settings.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Cantor, Scott E.
As far as I know 3.0 should be signing if the IdP metadata asks for it, so that would be a regression, assuming it worked in 2.x. I'll check into it on Monday. The conditional behavior is very complex. But I would not have expected 3.0 to break it, it was a 2.6 change to complicate all that code.

This even came up back then:

https://issues.shibboleth.net/jira/browse/SSPCPP-783

The conclusion was that it was behaving as intended in 2.6 and that it honored the metadata by default.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Cantor, Scott E.
In reply to this post by Wessel, Keith William
On 7/20/18, 6:19 PM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Wessel, Keith William
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 <[hidden email]> On Behalf Of Cantor, Scott
Sent: Sunday, July 22, 2018 11:26 AM
To: Shib Users <[hidden email]>
Subject: Re: Does SP3 not sign authn requests by default?

On 7/20/18, 6:19 PM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> 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 [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Cantor, Scott E.
On 7/25/18, 5:00 PM, "users on behalf of Wessel, Keith" <[hidden email] on behalf of [hidden email]> wrote:

> 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.

That's probably something subtle connected to the legacy configuration support but I don't know whether the change is intentional or not. I would guess it's a bug, and even if not I hadn't documented it as changing.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Cantor, Scott E.
Offhand, my read of the code is that it wouldn't work in V3, and I'm surprised it worked in V2. I don't see how it would.

The old docs didn't have much that was precise about the <SSO> element, but it never suggested that option would work, and the V3 docs are most likely just wrong about it, by accident of reformatting and Rod guessing about it.

But they didn't try it because of the new docs, it somehow got done before by accident obviously.

So I would say it's not exactly a bug or a "change" in the sense that it was never a documented approach that was broken because of some change I made. It apparently was something somebody tried by accident and happened to work. Confluence of unfortunate circumstances, I think.

I'm puzzled enough to want to know why it worked before though because I can't see that being supported in the code.

Basically, putting it down "below" the ApplicationDefaults options is something you do if you had multiple SessionInitiator handlers defined and you wanted different custom options on each one. Since only the SAML2 handler signs anyway, this doesn't really matter in the case of the signing option so it's not something one would do that way, it belongs on the ApplicationDefaults element or in a RelyingParty element if it's a per-IdP setting.

So I wouldn't bother filing a bug on it, but I'll probably look at it a bit at some point so that I can accurately document it.

Weird though.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Cantor, Scott E.
Actually, I take that back, I think it is an unintentional change now that I got to the bottom of it. There are some rarely used options that work in the updated configuration namespace but don't get handled correctly in the legacy namespace, so it's a regression.

I don't know yet if I'll try to fix it, they're rarely used enough that documenting it is probably simpler. This is probably the most common one to be impacted. Most people can update to the new namespace very quickly anyway if the location of the setting has any real importance, which isn't the case here.

-- Scott


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does SP3 not sign authn requests by default?

Takeshi NISHIMURA
Schema declares that conf:SessionInitiatorGroup attributes can also be applied to a <SSO> element, so I thought all such settings are delivered to /Shibboleth.sso/Login .
It is safe to do so at least in 2.0 configuration.

If not, we have to warn all deployers to check their <SSO> before applying "yum update".

Best regards,
Takeshi

On 2018/07/26 10:14, Cantor, Scott wrote:
> Actually, I take that back, I think it is an unintentional change now that I got to the bottom of it. There are some rarely used options that work in the updated configuration namespace but don't get handled correctly in the legacy namespace, so it's a regression.
>
> I don't know yet if I'll try to fix it, they're rarely used enough that documenting it is probably simpler. This is probably the most common one to be impacted. Most people can update to the new namespace very quickly anyway if the location of the setting has any real importance, which isn't the case here.
>
> -- Scott
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Cantor, Scott E.
> Schema declares that conf:SessionInitiatorGroup attributes can also be
> applied to a <SSO> element, so I thought all such settings are delivered to
> /Shibboleth.sso/Login .

It isn't that simple but yes, for the most part.

> If not, we have to warn all deployers to check their <SSO> before applying
> "yum update".

There are a very small number of settings affected.
 
-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Cantor, Scott E.
> > If not, we have to warn all deployers to check their <SSO> before
> > applying "yum update".
>
> There are a very small number of settings affected.

It may actually only be that one setting, I thought there was a wider structural problem with it. If it's just one setting I'll treat it as a bug and patch it, but I don't know when 3.0.2 will be released. I really don't think very many people will be affected by it in the meantime.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Wessel, Keith William
Shall I file this as a bug and let you decide if it's worth fixing? If it's not fixed, it's probably worth documenting at the least for any unsuspecting folks who could prevent a service interruption if they know about it ahead of time.

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Thursday, July 26, 2018 8:22 AM
To: Shib Users <[hidden email]>
Subject: RE: Does SP3 not sign authn requests by default?

> > If not, we have to warn all deployers to check their <SSO> before
> > applying "yum update".
>
> There are a very small number of settings affected.

It may actually only be that one setting, I thought there was a wider structural problem with it. If it's just one setting I'll treat it as a bug and patch it, but I don't know when 3.0.2 will be released. I really don't think very many people will be affected by it in the meantime.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Cantor, Scott E.
> Shall I file this as a bug and let you decide if it's worth fixing? If it's not fixed,
> it's probably worth documenting at the least for any unsuspecting folks who
> could prevent a service interruption if they know about it ahead of time.

I filed it. In practice, documenting it is not going to help a lot because people don't read that first. I thought fixing it was going to be too invasive but it appears to be isolated to one case so it's better to just fix it and move on.

I really think they just got unlucky, we've never done anything anywhere but illustrate turning on signing in the more usual way.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Does SP3 not sign authn requests by default?

Wessel, Keith William
Agreed that they got unlucky. I have no idea why they turned it on in the SSO element. I don't recall suggesting that to them, and they didn't recall when or why they they did it that way or even that they did it. Granted, they were the ones who came to me asking me to enable skipping endpoint validation for their SP.

At any rate, thanks.

Keith


-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Thursday, July 26, 2018 9:24 AM
To: Shib Users <[hidden email]>
Subject: RE: Does SP3 not sign authn requests by default?

> Shall I file this as a bug and let you decide if it's worth fixing? If
> it's not fixed, it's probably worth documenting at the least for any
> unsuspecting folks who could prevent a service interruption if they know about it ahead of time.

I filed it. In practice, documenting it is not going to help a lot because people don't read that first. I thought fixing it was going to be too invasive but it appears to be isolated to one case so it's better to just fix it and move on.

I really think they just got unlucky, we've never done anything anywhere but illustrate turning on signing in the more usual way.

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
12