Page Comparison

Legacy File(s): conf/services.xmlCurrent , conf/services.properties

Format: Native Spring

Legacy V2 File(s): conf/services.xml, idp.properties, system/conf/services-system.xml
Format: Native Spring

Overview

The services.xml file is used to specify many of the other configuration files (or in general, resourcesmore generally, Spring Resources) to load to configure various important services within the IdP. It . The services.properties file provides a less granular way to identify the Spring beans containing the lists of resources, and also controls the dynamic reloading policy for behavior of those services.

You might modify this file these files to:

• change the files resources used, or more commonly add additional resources to supplement built-in defaults
• use configure more specialized approaches such as Subversion resources

Compatibility Notes

...

• or remote HTTP resources
• control how often to check for changes and reload configurations, if at all

The services.xml file in 2.x, but in 3.0 this file is now a native Spring bean file and the older services schema is not supported.

Contents

The file should contain a series of Spring bean lists that specify contains a series of "list" beans that specify the Spring Resources to load into various services. The lists are named with specific bean IDs that must not be changed, as these (see below) that direct the resources into the various services. If you wish to supply your own resource lists without modifying the delivered lists, you may control the bean IDs used by modifying services.properties.

Properties

The following idp.properties may be set to control the reloading and fail-fast behavior of the various services. Missing properties will default a service to non-failfast and non-reloading behavior.

# Reload "failfast" (stop the IdP if a configuration is bad)
# and reload check interval (0 or missing == never reload).

idp.service.logging.failFast=true
idp.service.logging.checkInterval=PT5M

# Relying Party resolver
#idp.service.relyingparty.failFast=true
idp.service.relyingparty.checkInterval=PT5M

# Metadata resolver
#idp.service.metadata.failFast=true
#idp.service.metadata.checkInterval=PT5M

# Attribute resolver
#idp.service.attribute.resolver.failFast=true
idp.service.attribute.resolver.checkInterval=PT5M

# Attribute filter
# Failing the filter fast leaves no filters enabled.
#idp.service.attribute.filter.failFast=true
idp.service.attribute.filter.checkInterval=PT5M

# NameID generation
#idp.service.nameidGeneration.failFast=true
idp.service.nameidGeneration.checkInterval=PT5M

Notes

Services that are configured using non-Spring syntax require an additional resource be loaded in order to enable Spring property replacement to work, and you should not remove that reference.

You can use any kind of resource supported by Spring, along with an addition custom resource type defined in the IdP for handling Subversion resources.

...

Fail Fast

The fail-fast behavior, which can be adjusted by service to a limited degree, determines whether the IdP webapp context will initialize and serve clients if a particular service fails to initialize successfully. The point of this mechanism is to allow you to decide for yourself when problems should be discovered and how serious they should be treated. While it isn't the default, you may find it simpler when first starting out to enable fail-fast behavior globally while you work through mistakes.

Whether a given service succeeds or fails is ultimately an internal consideration, but generally we're talking about whether its configuration is valid and whether its pieces and parts themselves are considered to be successfully initialized. Often there may be individual fail-fast settings applying at the micro level that in turn dictate whether the surrounding service starts (and which then determines the overall result of the IdP startup process based on the service's fail-fast behavior). On top of that, some of the subsystems cause ripple effects when they fail that may make it impossible to really achieve non-fail-fast behavior in some cases.

As of V3.2, there are two levels of fail-fast properties that control service behavior (and described below). A global property called idp.service.failFast can be used to toggle all services to fail-fast at once (since the default is false for most, but true for a couple). In addition, or instead, you can control the behavior of specific services with properties specific to each service. The individual properties override the global setting, so you can mix and match.

Reloading Services

In addition to the "checkInterval" properties listed below to automatically reload services, you may reload a service at any time using the reload-service command line utility and the service ID. The service IDs are shown below in the Beans table (excluding the logging service, which is "shibboleth.LoggingService").

$ ./reload-service.sh -id shibboleth.AttributeResolverService

GET http(s)://[idp-base-url]/idp/profile/admin/reload-service?id=shibboleth.LoggingService

Reference

Beans

Beans defined in services.xml follow:

Properties

Properties defined in services.properties follow:

V2 Compatibility

A similar function was performed by the services.xml file in V2, but in V3 this file is now a native Spring bean file and the older services XML schema is not supported or used.

Additionally, the V2 ResourceFilter feature is also not supported, so if you're using the Property Replacement Filter feature, you will need to adjust at least some of your configuration files. In most cases (but not always) you can leverage the Spring property replacement mechanism by changing the syntax slightly.

Advanced Notes

You can use any kind of Resource supported by Spring, along with additional custom resource types provided with the IdP for handling Subversion and HTTP resources.