Support for X509SubjectName Name ID

Ullfig, Roberto Alfredo rullfig at
Fri May 15 17:43:07 UTC 2020

Ah, I see. Is it just the Responses or the Assertions too?

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

On 5/15/20, 11:20 AM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at on behalf of rullfig at> 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
To unsubscribe from this list send an email to users-unsubscribe at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list