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 can has two optional attributes that control service reloading:
- configurationResourcePollingFrequency - the frequency, in seconds, the service's configuration(s) are polled
- 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 configuration files are not loaded. If a configuration resource fails to load because it can't be read, is invalid, or for some 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.