Support for X509SubjectName Name ID

[Ullfig, Roberto Alfredo]

How many InCommon SPs are probably insecure in this fashion? Does InCommon insert WantAssertionsSigned="true" into the metadata automatically or does it have anything else that would protect against such a SP? Would it be a good idea when releasing attributes to a new Service Provider to test forcing both values to false, after checking the metadata and see if the application sign-in works or not?

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Architecture and Development | ACCC
University of Illinois - Chicago
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Ullfig, Roberto Alfredo <rullfig at uic.edu>
Sent: Friday, May 15, 2020 1:47 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Support for X509SubjectName Name ID

The two SPs in question actually have WantAssertionsSigned="false" in their metadata.

---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Architecture and Development | ACCC
University of Illinois - Chicago
________________________________
From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Friday, May 15, 2020 10:38 AM
To: Shib Users <users at shibboleth.net>
Subject: Re: Support for X509SubjectName Name ID

On 5/15/20, 11:20 AM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at shibboleth.net on behalf of rullfig at uic.edu> wrote:

> Signing is the default - not following you.

You said "they worked with signing false and *also* with the defaults". I'm saying, yes, of course they did. If they worked with no signing, they certainly aren't going to notice the signing. The problem is what Steve just reinforced.

Either the response or the assertion MUST be signed. Signing neither MUST result in an SP failure. A successful outcome is a wide open security breach of that service.

But just setting both those properties to false doesn't absolutely imply no signing. WantAssertionsSigned="true" in SP metadata could be toggling one of them back on under the covers and obviating the apparent bug. But it gives you the set to triage immediately and verify whether that might be the case.

-- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200515/92f5ca0a/attachment.htm>