Recommended or "Best" Practices for Shibboleth IdP?

[Cantor, Scott]

On 9/30/20, 6:49 PM, "users on behalf of Wil Cooley" <users-bounces at shibboleth.net on behalf of wcooley at pdx.edu> wrote:

>    * As the default configuration does not automatically reload the metadata resolver, is this the recommended
> configuration?

Historically the aggregates in higher-ed made that non-viable and unstable without tons of RAM. That's less an issue now with MDQ (and not an issue at all for different kinds of deployments).

> This is where most of our routine changes happen, so it would be convenient to enable it.

You should not have "routine" changes to the metadata sources unless you're adding filters (and it's a more recent need to be doing filters at such scale). You should absolutely not have to add metadata sources on any but rare occasions because of the LocalDynamic approach.

> Auto-reload for CAS is also disabled for us, but not in the default settings, so I would also like to enable it too; it's
> probably the 2nd biggest source of routine changes. The configuration files are only updated with manual interaction, so
> these changes will not happen unattended. Are there non-obvious trade-offs or any substantial risk in enabling these?

CAS should generally be handled with SAML metadata and OIDC will eventually be the same. Metadata is necessary for tags, and tags are how most of the IdP should be customized at this point.

If there's a best practice that isn't widely understood, that's it. The old days of touching any files but metadata (or filters in the case of federation metadata) are essentially gone for me on any routine basis.

>    * How safe and non-interruptive is adding or removing metadata in a live environment? The service reloading seems 
> to be quite robust against errors in XML syntax and slightly permissive in validity and has recovered gracefully when I
> have seen errors (either introduced for testing or because an SP went away without anyone telling us).

I do it a lot but don't find much reason to not just do it myself when I deploy changes so the timing is controlled. I don't do much auto-reloading anymore simply because I don't change anything but metadata often. If I do change other services I reload them, and it works fine.

> There seems to be a slight stall of a few tens of a seconds (at most) when reloading,

There shouldn't be any stall, it's not happening in a request handling thread. The reload command itself will wait until the reload is done, though, it doesn't return until then.

>    * If I have a vendor that supplies metadata via URL that has no `validUntil` (so the vendor does not seem to expect the
> metadata to change), should I prefer to download manually and use `FilesystemMetadataProvider`, or let Shibboleth 
> handle the downloading with `FileBackedHTTPMetadataProvider`? The former reduces the number of "moving parts",
> while the latter makes it easier to know if an SP goes away and our local customers have neglected to tell us to remove
> it.

Well, neither, you'd use LocalDynamic now for one-offs. I have one Filesystem source that's for my scripted metadata, mostly on-campus, but the rest is all in fragment files now.

I would never rely on any source of metadata but a federation (*) that's signing it and understands the trust model. Vendors do not. I have maybe 2-3 out of 150+ that I think could be trusted not to break their system by changing their metadata improperly but the lack of metadata support in their customer base means that they have to notify everybody anyway so having it consumed from a remote source wouldn't accomplish anything but introduce a point of failure.

The lack of validUntil on the order of weeks, or a signature under a separate key, is instantly disqualifying for any source of metadata because there is no viable trust model without them.

-- Scott

(*) Or a local customer feed being operated reasonably or whose impact in the case of problems would only be to shoot themselves in the foot.