Question about best practice regarding release of deprecated encodings

[Bellina, Brendan]

On 11/10/15, 1:52 PM, "users on behalf of Cantor, Scott"
<users-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

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

The horse has left the barn. I won¹t ask for a show of hands of IdP¹s who
have done this or something very like it. So assume some SAML 2 SP¹s are
reliant upon this having been done and splitting out the invalid encoder
into its own silly attribute as has been suggested would be problematic
because without interrogating each SP you don¹t really know which encoder
they are dependent upon.  The time to have done that would have been when
each SP was upgraded to SAML 2. Now I suppose you would have to define
your silly attribute, then identify each SP that needs it, then create a
new attribute release policy for every one of those identified, and only
then could you safely remove the invalid encoder from the standard
definition. If there are many SP¹s then this does not sound like an
exercise that lends itself to speed and accuracy.

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

Without enforcement non-standard things are always going to creep into
production environments. No training exercises and no number of wiki pages
will be enough to prevent this kind of thing. ³Doctor, it hurts when I do
this.  So don¹t do this.² is not really a path out of the darkness.

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

Since the resolver is not SP scoped my guess is that whatever new feature
is available it probably would not help for this case.

It sounds like the best path forward within current capabilities would be
to create custom attributes with the invalid encoders for the SP¹s that
insist on them. As the SP¹s are identified switch them over to the custom
attributes.  After all SP¹s have been converted to the custom attributes,
fix the resolver attribute definitions.  After that if one of the SP¹s
decides to switch to the standard encoding then coordination will be
required between the SP and IdP change for that service to avoid an
impact.  Not quite the level of independence I was hoping for.

>
>-- Scott

Regards,

Brendan

>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net