Re: AttributeStatement differences IdP v3 → v4 ?

[Baron Fujimoto]

I suppose we were depending on it in the sense that we provided attr_2 to a
small number of SPs who were unable to consume our multivalued attr_1
directly. We essentially synthesized attr_2 as a version of attr_1 that
only provided a result for a specific potential value of attr_1. So it was
sort-of-not-really the same thing for the less capable SPs. We
distinguished them via their friendlyNames (and attribute IDs). Depending
on whether the SPs in question were consuming the attributes by their Name
or friendlyName, this may need to be accommodated if we change the
underlying Name. Regardless, thanks for the explanation. Now that we know
what the correct/expected behavior is going forward, we can work on fixing
things on our end with more confidence.

On Thu, Jun 30, 2022 at 3:31 PM Cantor, Scott via users <
users at shibboleth.net> wrote:

> You're probably talking about
> https://shibboleth.atlassian.net/browse/IDP-1936
>
> It is not a good idea in SAML to have two Attributes with the same name in
> an assertion, and while the Shibboleth SP handles that in a sane way, many
> won't (you might get the first one, the last, or both). I knew that it was
> doing that and I finally fixed it. It's always been broken, I think
> possibly as far back as the first versions, but I don't know for sure. It
> was just something you should never do, but I wanted it to do the right
> thing, finally, if somebody did it by accident.
>
> That should be the outcome you want if you're mapping two IdPAttributes to
> one SAML Attribute, otherwise you have little control over what the SP will
> do with it. If that's not what you want, you just shouldn't encode them to
> the same SAML Attribute.
>
> I don't see how you could have been "depending" on this before. A
> Shibboleth SP would have just combined them on the other end anyway, so
> it's not a change, and most other SPs wouldn't do anything predictable at
> all and you'd never want to depend on whatever they were doing.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://shibboleth.atlassian.net/wiki/x/ZYEpPw
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>


-- 
Baron Fujimoto <baron at hawaii.edu> ::: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum descendus pantorum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20220701/2b51b9af/attachment.htm>