Overview

The <ApplicationDefaults> element (and any nested <ApplicationOverride> elements) define most of the runtime behavior of the software when it processes SAML assertions and protocol messages. The usual pattern is to define most of this information once, in the outer element, and then supply a limited set of overridden information for each application you define that needs exceptional behavior.

Every request to the web server is associated with an application by the request mapper component. An application represents distinct collections of resources within the server's document tree that share the same general configuration requirements, although access control can be enforced on a finer-grained basis.

These application boundaries may or may not align with the notion of an application as understood in other contexts, but usually do. A very common strategy is for each virtual host on a server to map to its own application.

The majority of the SP's more advanced functionality is defined on a per-application basis. Supported protocol endpoints and handlers, security policies, credentials for signing, encryption, and TLS, attribute extraction/resolution/filtering, and the entityID to use are just some of the options handled here.

When a resource protected by the SP needs distinct behavior in these kinds of areas, a new application needs to be defined here and referenced by the request mapper using the applicationId property.

The <ApplicationDefaults> element both specifies default behavior and acts as a container for any other <ApplicationOverride> elements. <ApplicationOverride> elements inherit all the settings of the <ApplicationDefaults> element but can override them (see NativeSPApplicationOverride for details on how this works).

Basic Configuration (Version 2.4 and Above)

The default configuration of the <ApplicationDefaults> element and most of its subelements will work for most circumstances with a few modifications.

If specialized behavior for another application needs to be defined, use an <ApplicationOverride> child element.

Basic Configuration (Older Versions)

The default configuration of the <ApplicationDefaults> element and most of its subelements will work for most circumstances with a few modifications.

If specialized behavior for another application needs to be defined, use an <ApplicationOverride> child element at the end of the outer element's set of children.

Attributes

Relying Party Attributes

The following supported attributes are grouped because they can be overridden per-partner using a <RelyingParty> element:

Child Elements

On Version 2.4 and above, all but the first two elements may appear in any order. On older versions, the order MUST be as listed.

Also on Version 2.4 and above, elements that could not appear more than once unless explicitly "chained" may now appear multiple times and will be chained automatically. This includes <MetadataProvider>, <TrustEngine>, <AttributeExtractor>, <AttributeResolver>, and <AttributeFilter>.

Examples

The following shibboleth2.xml excerpt contains an example in which a second application with its own entityID is created on a second virtual host. This is one of the most common cases.

[...]

<!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
    <RequestMapper type="Native">
        <RequestMap applicationId="default">

            <Host name="service.university.org" authType="shibboleth" requireSession="true"/>
            <Host name="other.university.org" applicationId="other-app" authType="shibboleth" requireSession="true"/>

        </RequestMap>
    </RequestMapper>


[...]

<ApplicationDefaults id="default" policyId="default"
        entityID="https://service.university.org/shibboleth"
        homeURL="https://service.university.org/welcome/"
        REMOTE_USER="eppn persistent-id targeted-id"
        >

       [...]

        <!-- Overrides for other-app -->
        <ApplicationOverride id="other-app" entityID="https://other.university.org/shibboleth"/>
</ApplicationDefaults>

[...]

This excerpt is an example where the additional application is on the same virtual host. Notice the overriden handlerURL that also has to map to the overridden applicationId.

[...]

<!-- To customize behavior, map hostnames and path components to applicationId and other settings. -->
    <RequestMapper type="Native">
        <RequestMap applicationId="default">

            <Host name="service.university.org" authType="shibboleth" requireSession="true">
                <Path name="other-app" applicationId="other-app"/>
            </Host>

        </RequestMap>
    </RequestMapper>


[...]

<ApplicationDefaults id="default" policyId="default"
        entityID="https://service.university.org/shibboleth"
        homeURL="https://service.university.org/welcome/"
        REMOTE_USER="eppn persistent-id targeted-id"
        >

       [...]

        <!-- Overrides for other-app -->
         <ApplicationOverride id="other-app" entityID="https://other.university.org/shibboleth">
             <Sessions lifetime="28800" timeout="3600" checkAddress="false"
                handlerURL="/otherapp/Shibboleth.sso" handlerSSL="false">
        </ApplicationOverride>
   </ApplicationDefaults>

[...]