Clarification of failFastInitialization Metadata Option

[Cantor, Scott]

On 3/9/16, 7:31 PM, "users on behalf of Rising, Matt" <users-bounces at shibboleth.net on behalf of mrising at towson.edu> wrote:



>Recently we had a service provider whose MetadataProvider type is FileBackedHTTPMetadataProvider send us bad metadata—which caused the entire IdP to fail after a metadata reload.

Well, there is no scenario in which I would *ever* load metadata from a service provider. You are essentially giving them carte blanche to undermine the system.

But if you did, you'd best be sure you have a metadata whitelist filter in place to control exactly what entity you get from that metadata, or you're really opening yourself up in a very serious way.

So, that's issue #1 to note here.

But, unless you mean it failed when you actually restarted the IdP, I don't think that's related to fail fast behavior...

> 
>This begs the question:  What is the failFastInitialization=false MetadataProvider option actually used for?

To prevent one bad thing from preventing a restart of the IdP if everything else would work fine without it. Particularly in this area, since multiple metadata sources can be treated independently.

>It seems as though it’s just a switch between “fail now, massively” or “fail later in a weird, less-diagnosable way.”

I can't really speak to what other people would be able to diagnose, but I don't have any problems relying on it in many cases at many different levels. I don't think "completely fail" is a reasonable thing, but other people don't agree, so that's why the option is there.

>Testing the option on IdP V3 shows that the IdP does start, but then not even the /idp/status page will.

That's a trivial status page bug, already fixed. I ran into it while working on my upgrade.

> 
>So, not just operations for that service provider that provided bad metadata will fail, but any function that references metadata in any way will fail?

I don't know what you mean by that.

-- Scott