Question about best practice regarding release of deprecated encodings

[Cantor, Scott]

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



>My understanding is that the resolver is not SP specific, so you define
>each encoder you need within it.  An example of one demonstrating what I
>am talking about would have encoder lines like so:
>
><resolver:AttributeEncoder xsi:type="SAML1String"
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>                        name="urn:mace:dir:attribute-def:sn" />
><resolver:AttributeEncoder xsi:type="SAML2String"
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>                        name="urn:oid:2.5.4.4" friendlyName="sn" />
><resolver:AttributeEncoder xsi:type="SAML2String"
>xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
>                        name="urn:mace:dir:attribute-def:sn"
>friendlyName="sn" />

Right, that's just invalid. So, don't do that.

>In this case a SAML2 SP is going to get duplicated values of sn if it
>accepts both of the SAML2String encodings defined, which it may want to do
>because it has one IdP giving it OID and another giving it URN.

And one of those IdPs is misconfigured. If one was signing with the wrong key, the solution wouldn't be to accomodate it at an SP. I don't see how this is any different.

> I am asking if there is a way in the attribute release policy to indicate that
>for a specific SP I only want to use one of the SAML2String encodings, not
>both of them?

The attribute filter knows nothing about encodings whatsoever. Encoders in V3 can be controlled with conditions, but it's not part of attribute release, it's in the resolver. But it was done for a different use case, not to accomodate this. There is no reason an IdP would ever need to do this.

-- Scott