Page tree

The Shibboleth 2.x software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP30 and SP3 wiki spaces for current documentation on the supported versions.

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

Version 1 Next »

Every Shibboleth provider has configuration files that govern how it works. This section of the Wiki is a miniature encyclopedia that reflects the structure of the XML schemas that are involved in the core operations of an IdP and an SP. While browsing through it directly may make for good bedtime reading, we suggest you stick to the how-to's for most of your configuration needs. Information for community-contributed extensions may be found here.

Shibboleth's configuration flexibility often allows many different approaches to achieve the same functionality. These topics represent categories of configuration and not necessarily a recommended file structure.

IdP Configuration

The IdP is written as a Java servlet application and uses Spring to connect a large set of components together. The following is an incomplete summary of these components.

Attribute Authority Functionality

Attribute Resolver

Attribute Filters

Filter policies define how and when attributes are released to an SP or other requesting systems.

Metadata

Metadata defines a partner site's capabilities, endpoints, keys, and other useful information. The Shibboleth software implicitly trusts the metadata it is given and uses it as a basis for all of its runtime decisions and choices.

Native SP Configuration

The native SP is written in C++ and is integrated with various web servers directly using the proprietary APIs they provide. A mix of native server integration and portable configuration is provided (though native support is mostly confined to the Apache version). Most of the portable configuration is handled by various files in the /etc/shibboleth directory, but the web server configuration itself determines some of the SP's behavior.

Portable Configuration

Core

Most of the native SP's core functionality is defined in shibboleth2.xml. Read that topic for a detailed breakdown. Key subcomponents are also listed below.

Metadata

Metadata defines a partner site's capabilities, endpoints, keys, and other useful information. The Shibboleth software implicitly trusts the metadata it is given and uses it as a basis for all of its runtime decisions and choices.

Trust Engines

Trust engines provide the basis for authenticating messages from partner sites and securing the system in a "real world" sense.

Credential Resolvers

The SP loads its own keys and certificates (not to be confused with SSL certificates used by web servers) using these plugins.

Attribute Resolvers

The SP can resolve attributes from external sources (in addition to those it receives as part of SSO).

Attribute Extractors

The SP extracts attributes it receives from SAML assertions and prepares them for use by web applications using AttributeExtractor plugins. The default version is configured using an XML file such as attribute-map.xml.

Attribute Filters

Rules are applied to extracted and resolved attributes using attribute filter policies. The default version used by the native SP shares the same basic language and most of the features of the Java AFP implementation, and is configured with the attribute-policy.xml file.

Web Server Configuration

Some mandatory configuration is always required to integrate the SP with a web server. Some servers also support a degree of "native" integration enabling the SP to be partly controlled from the web server's own configuration file(s).

Microsoft's IIS (at least pre-7.0) does not provide for any significant native configuration capability, and no GUI integration into the IIS console is supported at this time.

  • No labels