InCommon Technical Discussions

["Cantor, Scott" <>]

On 11/3/17, 12:48 PM, 
"
 on behalf of Eric C Kool-Brown" 
<
 on behalf of 
>
 wrote:

> I agree with his assessment but I thought I’d expand on the context. ADFS 
> 4.0 requires metadata to be served on a TLS endpoint.
> OTOH, it isn’t clear if ADFS verifies  the signature on the metadata.

If it did, it would simply be blindly trusting the key used, so it wouldn't 
be meaningful. That part is clear from the (lack of) configuration.
 
> Scott’s valid assertion is that the trust model is based on signature 
> validation and not on encryption. There is this industry
> bandwagon that everyone use TLS but silence (or rather lame answers) when 
> one asks “why?” Do our cat videos really need to
> be encrypted?

When I spoke of its actual application of the metadata not being compliant, 
what I was specifically talking about was lack of support for [1], which 
means that the fundamental meaning of the metadata itself is not consistent 
between Shibboleth and ADFS. That extends to things like it breaking if the 
certificates expire, and more critically, we don't know how much it actually 
changes its behavior when it fetches a new copy of the metadata that's 
changed. In fact, I've had people tell me that it doesn't even ever refetch 
it at all, though I found that hard to believe.

So it's not even so much about the lack of of verification, but about the 
black box of what it's actually doing with it, making it difficult for me to 
know what my changes to the metadata will result in it doing differently.

-- Scott

[1] https://wiki.oasis-open.org/security/SAML2MetadataIOP