Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: add a few warnings

...

Then reload the IDP's Metadata service to make the new MetadataProvider configuration active:.

Note

Reloading the Metadata service as shown immediately below is only necessary in order to activate changes to your /opt/shibboleth-idp/conf/metadata-providers.xml configuration, not for changes to the metadata itself. So ideally you'd do this only once and be done with it. If you find youself adding new MetadataProviders all the time (e.g. one for each new SAML SP you intend to add) you're probably Doing It Wrong™ and should consider the alternative documented here.


No Format
/opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.MetadataResolverService

That should result in the message "Configuration reloaded." on the console, in being shown in your shell, a "Service 'shibboleth.MetadataResolverService': Reload complete" log entry in /opt/shibboleth-idp/logs/idp-process.log, as well as a web server log entry in /var/log/tomcat8/access.log. You should also see a new metadata backup file (with the file name configured above in the parameter backingFile) being generated in /opt/shibboleth-idp/metadata/.

The configured id="eduID.at" MetadataProvider will regularly and automatically reload and signature-validate eduID.at metadata, ensuring you always have current and authentic metadata available. If Though if you wanted you could also manually trigger reloads of the configured eduID.at metadata from the command line, e.g. when you wanted to avoid having to wait on the next reload. in the exceptional (and hypothetical) case you've been made aware of a service that was removed from eduID.at metadata for security reasons but your IDP is still using cached metadata containing that service.
In normal use of the IDP doing this is not necessarynot necessary, though:

No Format
/opt/shibboleth-idp/bin/reload-metadata.sh -id eduID.at

The id parameter's value needs to match the configured MetadataProvider's id XML attribute , value and only that metadata will be reloaded.

If Finally, in case you're following the provided example and also use using the id="LocalMetadata" MetadataProvider to manage your local (and bilateral) Service Provider metadata then you can manually reload metadata for those entities the same way, e.g. after having added a SAML Service Provider to : Because that metadata is "static" (it does not change unless you change it and it's not loaded over the network from where others would change it) the MetadataProvider for "LocalMetadata" does not contain any provisions for regular automatic reloading. As a consequence you will have to reload that specific metadata yourself each time you have changed the referenced /opt/shibboleth-idp/metadata/local-sps.xml metadata document:

No Format
/opt/shibboleth-idp/bin/reload-metadata.sh -id LocalMetadata

One could configure the IDP to reload that metadata automatically, too, but since loading incorrect metadata might break the IDP doing so automatically with self-managed metadata is not recommended. The ACOnet Team has extensive experience with curating and validating SAML Metadata for publication as part of the eduID.at metadata and so reloading that automatically is safe. The same may not be the case for the metadata you manage yourself, therefore we suggest adopting the method of manual reloading after having changed (and verified) the metadata.