Per-Entity Metadata Working Group

[Tom Scavo <>]

On Wed, Sep 7, 2016 at 12:30 PM, Paul Caskey 
<>
 wrote:
> The way I heard our discussion earlier was that http would be the primary 
> (and documented) path, same as always.
>
> But, we can also support https for those that need it.

How will "those that need it" know it's available if we don't document it?

Btw, "those that need it" are a very small proportion of all
deployments. Sure, we want to be all-inclusive but not at the expense
of the larger community.

> Regardless, http is the preferred path for most deployments.

You're preaching to the choir :-) and that's exactly my point. You
don't have to convince me; you somehow have to convince the average
deployer. By serving metadata over plain HTTP, we force the issue
(analogous to publishing front-channel bindings only).

> I think we can make this clear with correct verbiage, though I do agree 
> with your disappointments (in fact, you were generous, I would say 3 or 4 
> out of 5 don't understand it enough to run securely).

There is definitely a range of ability and experience. As we shift to
on-boarding the long tail of IdPs, the problem gets worse.

Tom

>> -----Original Message-----
>> From: 
>> 
>>  
>> [mailto:]
>>  On Behalf Of Tom
>> Scavo
>> Sent: Wednesday, September 07, 2016 11:23 AM
>> To: Per-Entity Metadata Working Group 
>> <>
>> Subject: [Per-Entity] supporting metadata distribution via HTTPS
>>
>> The following is not an Ops perspective (that’s a completely different
>> conversation :) I’m speaking now as a technical support person, one who
>> interacts with deployers every day. My overall experience is best described
>> as disappointing. I estimate that 2 in 5 deployers lack the knowledge 
>> and/or
>> experience to safely administer a SAML deployment.
>> Good documentation helps but not as much as you might think.
>>
>> Here’s a case in point: front-channel vs. back-channel protocols. Most
>> deployers do not understand why there are two use=”signing”
>> certificates in Shibboleth IdP V3 metadata. I tell them the front and back
>> channels have completely different security models and therefore best
>> practice dictates that each of the two channels rely on distinct key 
>> pairs. At
>> that point, most eyes gloss over.
>>
>> Recently, I’ve started to take a completely different approach when
>> consulting with deployers. All new IdP deployments are pushed firmly
>> towards front-channel bindings only. That sidesteps the difficult front-
>> channel vs back-channel security issue entirely. Out of sight, out of mind!
>>
>> We will have exactly the same problem if and when we start serving
>> metadata over HTTPS. The documentation that we have [1] will become
>> more complex. Deployers will see the little “s” in the metadata location 
>> and
>> blithely think all is well. Most will ignore the rest of the documentation.
>>
>> It’s ironic that the introduction of TLS might actually degrade the 
>> overall trust
>> fabric of the federation, but that is my fear.
>> Experience tells me that is a very real possibility.
>>
>> Tom
>>
>> [1] Metadata Client Software https://spaces.internet2.edu/x/QYG8Ag