Question about best practice regarding release of deprecated encodings

[Cantor, Scott]

On 11/10/15, 3:02 PM, "users on behalf of Bellina, Brendan" <users-bounces at shibboleth.net on behalf of bbellina at ucla.edu> wrote:



>If I am understanding correctly then it sounds like the best course would
>be for SP¹s to be configured to accept all encodings and the IdP use an SP
>specific attribute release policy to only release one.

I'm still searching for the problem you're trying to solve. Can you provide a specific case?

I migrated 250+ services from SAML 1 to SAML 2 (most here, but many off campus) and I never once had to do this.

>If the above is a reasonable approach, then would custom attributes be
>used, one for each encoding, or is there a way in the release rule to
>restrict release to a specific encoding so as to avoid duplicates?

V3 has conditional encodings, but that's so you can reuse attribute definitions and apply custom encodings for SPs not following standard naming. That's kind of a different problem, in the sense that you typically want to avoid sending a second copy of an attribute to every single system, but it doesn't cause any duplication or even get noticed if you do, really. Not many SPs have a problem ignoring unknown attributes, but that was one reason for the feature.

In V2, yes, you have to hack around that problem, there's no such feature. Or you just send the second copy and ignore it. Again, it doesn't break anything in most cases.

But there is no reason I've ever run into why you'd send a SAML 1 name in a SAML 2 response or vice versa (and be sending both at once). And that's about the only case where you'd be liable to trigger any issue at a (Shibboleth) SP. Even sending the *wrong* name doesn't actually break in many cases since the SP happens to be very (too) forgiving in its mappings. But you would never send both. That's just weird.

Basically, you have to really work to have a problem here. By far the more common cause of complaints about duplicates is the NameID overlap.

-- Scott