The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

IdP Configuration Configuration

This page provides information about various ways in which you can influence how the IdP loads/reads its configuration.

Loading Configuration Files

The service.xml configuration file provides information about all the other the configurations loaded into the IdP. Each service that reads a configuration may read any number of them. The result of reading more than one configuration is equivalent to merging all the configurations into one large file.

The IdP supports multiple mechanisms for fetching its configurations. The definition of what and how to fetch is known as a configuration resource and the IdP supports the following configuration resource types:

  • Classpath Resource - Read a configuration resource from the IdP's classpath.
  • Filesystem Resource - Reads a configuration file from the filesystem.
  • HTTP Resource - Reads a configuration document fetched from an HTTP URL.
  • File-backed HTTP Resource - Reads a configuration document fetched from an HTTP URL and caches it on the filesystem for use in the event that the remote server is unavailable.

Enabling Configuration Reloading

Most of the IdP configuration files can be watched and reloaded if a change is detected.

Caution

Do NOT enable configuration reloading in a production environment unless you have a rigorous configuration testing process in place and used.

Reloadable Services

The IdP contains four services which can be reloaded

  • attribute resolver - responsible for fetching and creating attributes, controlled by $IDP_HOME/conf/attribute-resolver.xml
  • attribute filtering engine - responsible for filtering attributes based on policy, controlled by $IDP_HOME/conf/attribute-filter.xml
  • profile handler manager - responsible for defining IdP endpoints (profile handlers), controlled by $IDP_HOME/conf/handler.xml
  • relying party configuration manger - responsible for managing per relying party configurations, controlled by _$IDP_HOME/conf/relying-party.xml

To enabled service, and hence configuration, reloading you edit the service definition in the service configuration file, $IDP_HOME/conf/service.xml. Each Service element has two optional attributes that control service reloading:

  • configurationResourcePollingFrequency - the frequency, in seconds, the service's configuration(s) are polled for changes
  • configurationResourcePollingRetryAttempts - number of times the IdP will attempt to reload a failed configuration before giving up, default value of 3.

If configurationResourcePollingFrequency is not specified services are never reloaded. If a configuration resource fails to load because it can't be read, is invalid, or for any other reason the IdP will continue to use the previous configuration. If the configuration file fails to load a number of times equal to configurationResourcePollingRetryAttempts, the IdP will stop trying to reload the file. A restart will be required to re-enabling polling.

  • No labels