Shibboleth IdP fails to download metadata then never tries again

[shibboleth655 at lewenberg.com]

On 8/11/2017 11:07 AM, Cantor, Scott wrote:
>> 3. However, there is *never* again a log entry indicating that Shibboleth IdP attempted to download the metadata at that URL.
>> It is as  if the IdP service stops trying.
> 
> Your evidence for that is what? The access log on the web server hosting the metadata?

Our evidence is simply that there are no messages in the IdP process log 
of the problematic server about an attempt to download that metadata 
file after the one with the error message.

On most of the members of our Shibboleth IdP pool that do *not* exhibit 
the issue, we see these messages in the Shibboleth process log about 
every 20 minutes or so:

idp-process.log:2017-08-16 08:07:38,317 - INFO 
[org.opensaml.saml.metadata.resolver.impl.AbstractReloadingMetadataResolver:465] 
- Metadata Resolver FileBackedHTTPMetadataResolver stanford-idps: New 
metadata successfully loaded for 
'https://idp.stanford.edu/Stanford-idps.xml'

But on the problematic server, after the error message about not being 
able to download the metadata file, no more messages, good or bad, in 
the process log about that metadata file.

On all the servers, the local backing file has a last-modified date 
matching the latest entry in the process log about that metadata file. 
So, the local backing file on the "good" servers has a last-modified 
date of no more than 20 or so minutes in the past, while the local 
backing file on the "bad" server its last-modified date of a couple 
weeks ago.

Note that the source metadata file itself has not changed since January 
2017.

Here is the relevant entry from metadata-providers.xml


     <MetadataProvider xsi:type="FileBackedHTTPMetadataProvider"
         id="stanford-idps" xmlns="urn:mace:shibboleth:2.0:metadata"
         metadataURL="https://idp.stanford.edu/Stanford-idps.xml"
         backingFile="/var/tmp/Stanford-idps.xml"
         minRefreshDelay="PT10M" maxRefreshDelay="PT30M">
             <MetadataFilter xsi:type="SignatureValidation" 
requireSignedRoot="true"
               certificateFile="${idp.home}/credentials/signing.pem" />
     </MetadataProvider>




> 
>> 4. This is a big problem as now our metadata is getting more and more stale.
> 
> Is the metadata at the source actually newer?
> 
>>   (After this point, there is NEVER again a mention of  https://idp.stanford.edu/Stanford-idps.xml&#39 in any of the logs.)
> 
> That doesn't really mean anything, there are issues with the logging around expired or unchanged metadata.
> 
> -- Scott
> 
> 
>