Page tree

Previous Stable Release

Please note that the V3 release branch is now the previous stable release, with the current stable releases from the V4 branch.
Support for V3 will end on Dec 31, 2020.

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 24 Next »

We apologize, but the configuration documentation is sparse for the moment.

For now, this is mostly presented as an outline of the changes in 3.0 and how to find the right places to configure specific features. The general thrust of this material is for the deployer who is familiar with 2.x, so many comparisons and notes about the differences and changes are made.

General Installation Structure

The installation layout of the beta release (and the planned layout of the final release) is as follows:

shibboleth-idp/					(root, referred to as idp.home)
	bin/						(scripts and utilities)
 	conf/						(user-modifiable configuration, untouched across upgrades)			(properties that plug into XML config in various ways)
 		authn/					(authentication-related configuration)
 		c14n/					(subject normalizing configuration)
	creds/						(credentials, keys, certificates)
	edit-webapp/				(overlay that replaces webapp files when war is built)
	flows/						(user-modifiable SWF definitions, untouched across upgrades)
	jetty-base/					(example Jetty configuration suitable for use with current Jetty versions)
	messages/					(internationalized messages for UI templates, untouched across upgrades)
	metadata/					(locally deployed metadata, backup for remotely hosted metadata)
	misc/						(additional useful files included with the install)
	system/						(internal system configuration, meant to be left alone)
	views/						(external-to-war Velocity UI templates, untouched across upgrades)
	war/						(packed war for deployment)
	webapp/						(unpacked war tree containing the Java webapp)

The most important difference from older versions is the separation of configuration files into user- and system-level files. The contents of the "system" directory and its subdirectories are meant to be left unmodified to as great an extent as possible. This is to ensure that backward-compatible upgrades can be accomplished safely without reapplying local changes, and so that core configuration changes required by newer versions can be applied automatically.

There are a number of interdependencies between the Spring configuration files in "conf" and "system" that are like a contract between the user configuration and the system configuration. In most cases, these dependencies can be identified via the use of bean identifiers that contain the prefix "shibboleth." When in doubt, don't change a bean id that contains such a prefix. Eventually the various required beans will be thoroughly documented.


The old 2.x support for "resource filters" that allowed for property replacement in configuration files has been replaced with a less generic but more supportable approach using Spring's property replacement layer. This allows for both arbitrary files containing properties, but also chaining back to the system environment or system properties set in Java. By default, we supply a file called that is processed at load time and is accessible as a property source for most of the configuration files.

Unfortunately, the syntax for Spring properties by default clashes with Velocity macro syntax, which causes problems in the attribute resolver configuration. To avoid this problem, the Spring syntax is customized to use a '%' character as a prefix. So properties in the files will appear as "%{propertyname}" or in some cases "%{propertyname:defaultvalue}". If you want to use your own properties, just keep in mind you need to use a different character than documented by Spring.

Configuration Areas

 Topics exist for each general configuration area to go into more detail on how to do various things or try out features:

Configuration Changes (and Non-Changes) from 2.x

You'll see a lot of new files in "conf" as well as a few familiar ones. There are three older files that are designed to work fully, or almost-fully, from 2.x:

  • attribute-resolver.xml
  • attribute-filter.xml
  • relying-party.xml

These are, not surprisingly, the files containing most of the frequently modified configuration in older versions. There are a few caveats to this compatibility, which are discussed in the subtopics discussing these particular files, but apart from the noted issues there, any failures to load or operate as expected with any older 2.x configuration files should be considered a high-priority bug and reported. We can't possibly test all the possible options out there, so it's critical that we get feedback on these issues prior to the release later this year to smooth the upgrade process. All regressions should be reported via JIRA.

The other files are essentially new configuration, or in a few cases are refactored subsets of the original relying-party.xml configuration, which is discussed in that subtopic.

The most noteworthy change is that authentication is configured very differently in 3.0. There is no handler.xml file any longer, but there are substantial overlaps in the common cases of the UsernamePassword or RemoteUser login handlers, and there's a similar feature to the External login handler. In particular, the hardest aspects of configuring those handlers should translate more or less directly to this version.


  • No labels