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

3.0 Alpha 1

This is extremely sparse documentation to aid in testing the alpha release of the Identity Provider 3.0 software. We will eventually have more complete documentation on par with, or hopefully better than, that available for 2.x, but that will take most of this year or longer to complete, so for now this is an outline of the changes in 3.0 and how to find the right places to configure specific features.

Those with experience running 2.x will find many similarities and significant compatibility, with the major difference being much more use of native Spring XML configuration for newer or enhanced features. For some helpful reference material on how native syntax works, see:

While the use of Spring Web Flow (SWF) for user interaction is a major change, we have tried to minimize the degree to which a typical deployer will need to interact with, let alone customize, flows. But we provide some notes on how and where this can be done for those with more ambitious needs.

General Installation Structure

The installation layout of the alpha release (and the planned layout of future releases) is as follows:

shibboleth-idp/						(root, referred to as idp.home)
	conf/							(user-modifiable configuration, untouched across upgrades)
		authn/						(authentication-related configuration)
	creds/							(credentials, keys, certificates)
	flows/							(user-modifiable SWF definitions)
	metadata/						(locally deployed metadata, backup for remotely hosted metadata)
	system/							(internal system configuration, meant to be left alone)
	views/							(external-to-war UI view templates, principally Velocity)

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 somewhat 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.

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.

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