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 Authority Command Line interface: The complete ingress and egress of attributes for a specific SAML-based transaction may be tested using the AACLI.
Attribute Resolver
- resolver.xml: Defines how Shibboleth interfaces with attribute sources.
- Static Data Connector: Always releases a fixed value for every user.
- Relational Database Data Connector: Links Shibboleth to a relational database.
- LDAP Directory Data Connector: Links Shibboleth to an LDAP v3 directory through JNDI.
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.
- Metadata Providers: Sources of metadata that describe partners to interact with.
- Metadata Filters: Filters metadata received from a metadata provider.
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.
...
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.
...
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.
...