Support for X509SubjectName Name ID
Ullfig, Roberto Alfredo
rullfig at uic.edu
Fri May 15 18:47:55 UTC 2020
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/7682d2d5/attachment.htm>
More information about the users
mailing list