IDP metadata in 3.0

[Cantor, Scott]

On 1/14/15, 9:00 PM, "Jacob Lundberg" <jacob at collegenet.com> wrote:


>
>Oh, I did not realize Tomcat 7 had been dropped for the new IdP.  Well,
>we should have Tomcat 8 support in Debian 8 in a few more months...

As a technical constraint, Tomcat 7 is new enough (apart from this detail, 
but JSP isn't heavily used in the IdP right now). As a support decision, 
there was no reason to support an out of date version for many reasons, 
and this is sort of a good validation of that.

>Perhaps large organizations like universities can afford to blow the IT
>hours on constantly upgrading Tomcat to get security fixes, but we
>really appreciate the effort distributions put into backporting security
>fixes so we aren't forced to deal with upgrade fall-out very often when
>applying security fixes.

With modern containers, patch upgrades are trivial, because the BASE 
directories are separate from the distribution tree. But more to the 
point, the distributions break these packages in nasty ways that lead to 
hours spent debugging problems that never existed until the code got 
packaged. OpenJDK has a similar problem.

Jetty also has a much better track record on security than Tomcat in 
recent years, which was one of the many reasons we switched 
recommendations.

Anyway, I run the official packages to save me time as a deployer, and it 
definitely has.

>I do want to say we really appreciate the effort you put into support,
>Scott, particularly when you are answering questions from customers like
>us who are not on officially supported platforms.

Answering is easy, it's reproducing bugs that we have to stick to an 
official policy on.

>Heh!  I think the documentation is quite clear nobody is supposed to
>provide their metadata directly from the IdP.  However in practice it is
>also clear many users of the IdP software either do not read the
>documentation or do not care.

I didn't meant that, rather whether we implied or stated that the servlet 
path itself was meant to be a stable location.

>And yes, when consuming metadata from any source besides InCommon, we
>filter it to only include the expected entity ID.  We also require valid
>SSL certificates, although I suspect this provides very little actual
>security benefit.

Filtering that is very significant, and is something I don't think people 
doing this usually do, which is why it tends to be a bad idea for most 
people.

-- Scott