Question about best practice regarding release of deprecated encodings

[Bellina, Brendan]

My thanks to everyone who responded.  I think there is enough information
now to plot a course.  If there is anyone else who encountered this
problem at their institution and would like to discuss the situation
privately you can contact me off-list at bbellina at ucla.edu.

And maybe I’ll get a free beer out of Scott over this, so good thread all
around. :)

Regards,

Brendan Bellina
Identity Mgmt. Architect, IT Services, UCLA



On 11/10/15, 5:12 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, 5:34 PM, "users on behalf of Bellina, Brendan"
><users-bounces at shibboleth.net on behalf of bbellina at ucla.edu> wrote:
>
>
>
>>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.
>
>If you don't know where the problem is (or if it even exists), then what
>solution could be applied? I can't think of any.
>
>>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.
>
>That doesn't mean those things can be fixed for free, or ignored, though.
>
>>Since the resolver is not SP scoped my guess is that whatever new feature
>>is available it probably would not help for this case.
>
>As far as I can tell, everything you proposed assumes you have the
>knowledge of which SPs are affected. If you have that information, then
>the V3 feature addresses (though not intentionally) the continued
>practice of this kind of mistake, and the V2 workaround essentially does
>that as well.
>
>If you don't know which SPs are affected, then I'm not clear on what
>solution you're looking for or how it could work.
>
>>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.
>
>By definition, the only SPs that could need this are the ones you already
>work with. So you've already scoped the problem. Also by definition, they
>must be working now or you'd already have to fix something. So presumably
>a starting point, you'd change things so that all those SPs immediately
>received the workaround attribute, and everything else going forward
>would get the correct one.
>
>At that point, you can take a number of approaches. Virtually no
>Shibboleth SP could possibly have this problem. So given metadata you
>could rule out a lot of the SPs right away. If you wanted even more
>assurance, you could test them via push responses against a copy of the
>IdP with the fixed config via /etc/hosts, and rule them in or out. I bet
>you'd be left with very few questionable cases.
>
>And honestly, I'd bet you a beer you couldn't find 10 that have this
>mistake. There may be some SAML 1 only SPs that don't have attribute
>mappings for SAML 2, but you don't make them work by fooling them. And
>you don't have to. Just keep using SAML 1 with them and everything is
>fine.
>
>-- Scott
>
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net