Most of the native service provider's configuration options are found in shibboleth2.xml, located in the SP's main configuration directory. This location varies by installation, but will commonly be /etc/shibboleth/shibboleth2.xml or /opt/shibboleth-sp/etc/shibboleth/shibboleth2.xml.

For help with initial configuration, check the Getting Started topic. This page is a general reference to help with advanced use.

The primary configuration file consists of an <SPConfig> element that contains one each of several other top-level elements, each representing a category of SP configuration, and optional extensions. Each of these is described in its own section, linked below.

<SPConfig xmlns="urn:mace:shibboleth:sp:config:2.0"
	xmlns:conf="urn:mace:shibboleth:sp:config:2.0"
	xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
	logger="syslog.logger" clockSkew="180">

    <Extensions/>

    <OutOfProcess/>

    <InProcess/>

    <Listener/>

    <StorageService/>
    <SessionCache/>
    <ReplayCache/>
    <ArtifactMap/>

    <RequestMapper/>    

    <ApplicationDefaults id="default" policyId="default"
        entityID="https://sp.example.org/shibboleth"
        homeURL="https://sp.example.org/index.html"/>

    <SecurityPolicies/> <!-- Earlier Releases -->
    <SecurityPolicyProvider/> <!-- 2.4 and Above -->

    <ProtocolProvider/> <!-- 2.4 and Above -->

    <ds:Signature/> <!-- 2.4 and Above -->

</SPConfig>

Attributes

Child Elements

Starting with Version 2.4, many of these elements are optional and are omitted from the default configuration file. More complete examples suitable for copying can be found in the example-shibboleth2.xml file. The associated pages describe the default settings used when various elements are omitted.

The majority of the SP's behavior is defined on a per-application basis. An application is an internal organizing concept that defines a set of configuration options for related sets of resources. These applications may or may not directly align with the web applications that are protected by the SP, but often do. For extensive discussion of this concept, refer to the NativeSPApplicationModel topic.