Question about best practice regarding release of deprecated encodings

[Cantor, Scott]

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