Recommended or "Best" Practices for Shibboleth IdP?

[Wil Cooley]

I have been the primary Shibboleth administrator at my institution for a
year now, so I have gotten quite familiar with it, enough that I was able
to upgrade from 3.3 to 4.0.1 a few weeks ago without issue. I was fortunate
to inherit a fairly mature implementation, which has made it a good deal
easier.

I have a few nagging questions about recommended practices:
* As the default configuration does not automatically reload the metadata
resolver, is this the recommended configuration? This is where most of our
routine changes happen, so it would be convenient to enable it. 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?
* 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). There seems to be a
slight stall of a few tens of a seconds (at most) when reloading, but I
ensure reloads happen serially with 3 different hosts. We used to manually
cycle the Shibboleth hosts in our load balancer pool but I have stopped
because that seems to be unnecessary overhead.
* 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.

Wil
--
Wil Cooley <wcooley(at)pdx.edu>
OIT-TI Identity and Access Management
Portland State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200930/98de183f/attachment.htm>