Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

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.

...

  • 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:

Include Page
NativeSPRelyingPartySettings
NativeSPRelyingPartySettings

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.

...

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.

Code Block

[...]

<!-- 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.

Code Block

[...]

<!-- 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>

[...]