Support for X509SubjectName Name ID

Ullfig, Roberto Alfredo rullfig at
Fri May 15 14:21:22 UTC 2020

OK fixed that, there were a handful - the settings must have been set false while testing a new SP implementation then propagated to a few others. All applications work with default settings now.

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 8:08 AM
To: Shib Users <users at>
Subject: Re: Support for X509SubjectName Name ID

On 5/15/20, 8:13 AM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at on behalf of rullfig at> wrote:

> So I was working on two of these non-InCommon ones yesterday and both had the same issue - so it seems like there's a
> new pattern to see for some of the new service providers. One was Azure and the other I'm not sure. Anyway, usually in
> the past I have this in relying-party for the non-InCommon ones:

Uh. You realize that's completely insecure? You can do it, and then any SP that doesn't break is known to be fully and totally broken. (An exception is when the metadata signals assertion signing.)

> but in this case they both expected signed responses. Have never seen that before but maybe it's an Azure thing.

Signed responses are the normal best practice in SAML 2 and the default.

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