Page tree
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 5 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.

Features Done or TBD

In general, 3.0 is a small superset of 2.x features at this stage, with a couple of exceptions.

Audit logging is not yet present, and general logging is a first draft at this stage, so lots on DEBUG, not much analysis of what's needed on INFO or WARN.

We have not yet added functionality from uApprove, so that matches 2.x at this point.

At least partial working functionality for all supported 2.x profiles is present, with the exception of the partial logout support added in 2.4, which is not yet added to 3.0.

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)
		idp.properties			(properties that plug into XML config in various ways)
		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 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 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.

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