Note that I first completed bug report #JOST-220, but it is closed and it is probably a better option to open a new issue here.
We are running a 2.4.0 Shibboleth IdP.
Yesterday we noticed that our IdP had failed to synchronize our federation metadata. It resulted in the IdP failing to answer SPs authentication requests with the following error message : WARN [org.opensaml.saml2.binding.security.SAML2AuthnRequestsSignedRule:81] - SPSSODescriptor role metadata for entityID 'https://rms.renater.fr/' could not be resolved
The problem was manually fixed with an IdP restart, thus refreshing the local copy of the metadata.
Here is what our metadata definition looks like in the relying-party.xml file :
Nothing relevent I could find in idp-process.log or catalina.out.
Strange coincidence : a French university (u-paris2.fr) has just reported the same issue today; their metadata file had not been updated for 5 days. They also had to restart their IdP. They are also using Shibboleth IdP 2.4.0.
Because we have the hand on the metadata distribution server too, I had a look at its Apache logs, looking for the IP address of our IdP. It shows below that metadata get downloaded every 3 hours, but downloads stopped for 5 days :
This was logged against 2.4.0 I think this was likely resolved with the many fixes we subsequently made in 2.4.1+, with HC timeouts, and metadata providers using their own Timer instances. So just coing to close this out as a duplicate.
Not a snowflakes of fixing this in the V2 time frame.
There has been an indicatiion that memory shortage may be implicated with the silent failure of some of the Apache HTTP Client
Rod Widdowson
July 5, 2015 at 12:12 PM
See JSE-14.
The V2 code is completely different from the V3 code, but I'll look at it for similar bugs
Scott Cantor
April 3, 2014 at 1:44 PM
Why is it better, when the original issue is already closed? Unless you're running with a patched library from that fix and are still experiencing this, we have no reason to pursue it.
Note that I first completed bug report #JOST-220, but it is closed and it is probably a better option to open a new issue here.
We are running a 2.4.0 Shibboleth IdP.
Yesterday we noticed that our IdP had failed to synchronize our federation metadata. It resulted in the IdP failing to answer SPs authentication requests with the following error message : WARN [org.opensaml.saml2.binding.security.SAML2AuthnRequestsSignedRule:81] - SPSSODescriptor role metadata for entityID 'https://rms.renater.fr/' could not be resolved
The problem was manually fixed with an IdP restart, thus refreshing the local copy of the metadata.
Here is what our metadata definition looks like in the relying-party.xml file :
<metadata:MetadataProvider id="RENATERMD" xsi:type="metadata:FileBackedHTTPMetadataProvider" metadataURL="https://services-federation.renater.fr/metadata/renater-metadata.xml" backingFile="/opt/shibboleth-idp/metadata/renater-metadata.xml"> <metadata:MetadataFilter xsi:type="metadata:ChainingFilter"> <metadata:MetadataFilter xsi:type="metadata:RequiredValidUntil" maxValidityInterval="P7D" /> <metadata:MetadataFilter xsi:type="metadata:SignatureValidation" trustEngineRef="shibboleth.MetadataTrustEngine" requireSignedMetadata="true" /> <metadata:MetadataFilter xsi:type="metadata:EntityRoleWhiteList"> <metadata:RetainedRole>samlmd:SPSSODescriptor</metadata:RetainedRole> </metadata:MetadataFilter> </metadata:MetadataFilter> </metadata:MetadataProvider>Nothing relevent I could find in idp-process.log or catalina.out.
Strange coincidence : a French university (u-paris2.fr) has just reported the same issue today; their metadata file had not been updated for 5 days. They also had to restart their IdP. They are also using Shibboleth IdP 2.4.0.
Because we have the hand on the metadata distribution server too, I had a look at its Apache logs, looking for the IP address of our IdP. It shows below that metadata get downloaded every 3 hours, but downloads stopped for 5 days :
193.49.159.13 - - [24/Mar/2014:23:31:25 +0100] "GET /metadata/renater-metadata.xml HTTP/1.1" 200 4061027 "-" "Jakarta Commons-HttpClient/3.1" 193.49.159.13 - - [25/Mar/2014:02:31:12 +0100] "GET /metadata/renater-metadata.xml HTTP/1.1" 200 4061027 "-" "Jakarta Commons-HttpClient/3.1" 193.49.159.13 - - [25/Mar/2014:05:31:13 +0100] "GET /metadata/renater-metadata.xml HTTP/1.1" 200 4061027 "-" "Jakarta Commons-HttpClient/3.1" 193.49.159.136 - - [25/Mar/2014:13:59:06 +0100] "GET /metadata/renater-metadata.xml HTTP/1.1" 200 4064555 "https://services.renater.fr/federation/technique/metadata" "Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0" 193.49.159.13 - - [31/Mar/2014:09:20:07 +0200] "GET /metadata/renater-metadata.xml HTTP/1.1" 200 4087422 "-" "Jakarta Commons-HttpClient/3.1" 193.49.159.13 - - [31/Mar/2014:12:20:09 +0200] "GET /metadata/renater-metadata.xml HTTP/1.1" 200 4087422