Support for X509SubjectName Name ID

[Ullfig, Roberto Alfredo]

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

On 5/15/20, 8:13 AM, "users on behalf of Ullfig, Roberto Alfredo" <users-bounces at shibboleth.net on behalf of rullfig at uic.edu> 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 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/68e8710d/attachment.htm>