Page Comparison

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.

...

• The entityID attribute on the <ApplicationDefaults> element needs to be changed to the SAML entityID you'd like to use for your deployment. This must be the value your federations and partners are expecting.

• Configure SSO to an IdP or with a Discovery Service
  • To use a specific IdP, change the entityID setting in the <SSO> element to match the value in that IdP's metadata.
  • To use a discovery service, remove the entityID setting in the <SSO> element, and set the discoveryProtocol and discoveryURL settings appropriately.

...

• The entityID attribute on the <ApplicationDefaults> element needs to be changed to the SAML entityID you'd like to use for your deployment. This must be the value your federations and partners are expecting.

...

• policyId (string) (optional on 2.4+, else required for <ApplicationDefaults>, optional for <ApplicationOverride>)
  • References a policy defined in the <SecurityPolicies> element. When omitted on Version 2.4 and above, the default policy is assumed.

• requireAuthenticatedCipher requireAuthenticatedEncryption (boolean) (defaults to false) (Version 2.5 and Above)
  
  • When true, the SP will refuse to decrypt assertions that are unprotected by a signature or an authenticated transport (e.g., back-channel TLS) unless the data is encrypted with a special type of cipher algorithm that includes built-in integrity protection to prevent chosen ciphertext attacks. At the present time, this will generally block use of encryption unless signed responses are enabled by an IdP.

...

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.

...

• <MetadataProvider> (zero or more on 2.4+, else required for <ApplicationDefaults>, optional for <ApplicationOverride>)
  • Supplies metadata about identity providers.

• <TrustEngine> (zero or more on 2.4+, else required for <ApplicationDefaults>, optional for <ApplicationOverride>)
  • Controls how trust processing is performed to determine whether authentication of messages from identity providers succeeds or fails, including XML and simple signing, and SSL/TLS. In later versions, the default configuration used when none are specified is to chain the ExplicitKey and PKIX engines together.

• <AttributeExtractor>(zero or more on 2.4+, else zero or one)
  • Controls how SAML attributes are decoded and exposed to applications.

...

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>

[...]