Page Comparison

...

When you use virtual hosting, there is no special handler configuration neeeded; you can simply inherit the default settings because the handlers will automatically be specific to each virtual host. When a request comes into https://myapphost.example.org/Shibboleth.sso/SAML2/POST, it will automatically be recognized as bound for the new application on that virtual host. All you have to do is ensure that the metadata you provide for the SP includes the necessary endpoints on that virtual host.

In contrast, when you divide things by path, you have to explicitly add XML to the configuration to establish a special handlerURL for the new application, as well as providing the necessary metadata. Typically it will look something like this:

<RequestMap applicationId="default">
    <Host name="www.example.org">
        <Path name="myappfolder" applicationId="myappname"/>
    </Host>
</RequestMap>
...
<ApplicationDefaults ...>
...
    <ApplicationOverride id="myappname">
        <Sessions lifetime="28800" timeout="3600" checkAddress="false" handlerURL="/myappfolder/Shibboleth.sso" />
    </ApplicationOverride>
</ApplicationDefaults>

...

Once you have the additional application defined, you can proceed to define any new settings you need, and correcting the SP's metadata. The metadata can be taken care of first (see the following two sections). Below that, you'll find the precise rules for how settings get inherited, and some example configurations for typical use cases involving application overrides.

The built-in Metadata generator, located by default at /Shibboleth.sso/Metadata, is unable to automatically generate metadata for application overrides. You'll need to create the metadata by hand. See MetadataForSP for more information about writing your own SP metadata file

...

The most common case is usually wanting to virtualize the SP by making an application act as a new logical SP with a different entityID. This is very simple.

<ApplicationOverride id="myappname" entityID="https://myapp.example.org/shibboleth"/>

...

As noted earlier, when you supply a custom <Sessions> element, you don't need to repeat all of the child elements that define the handlers unless you want to change them in some way also.

<ApplicationOverride id="myappname">
    <Sessions lifetime="28800" timeout="3600"
        handlerURL="/myapppath/Shibboleth.sso" handlerSSL="true"
        cookieProps="; path=/myapppath; secure; HttpOnly"/>
</ApplicationOverride>

If you want to customize the IdP metadata used by an application, you simply provide the desired <MetadataProvider>.

<ApplicationOverride id="myappname">
    <MetadataProvider type="XML" file="idpformyapp-metadata.xml"/>
</ApplicationOverride>

If you want to customize the SAML attribute handling for an application, you simply provide the desired <AttributeExtractor>.

<ApplicationOverride id="myappname">
    <AttributeExtractor type="XML" file="myapp-attribute-map.xml"/>
</ApplicationOverride>

If you want to assign a different private key or certificate to an application, you simply provide the desired <CredentialResolver>.

<ApplicationOverride id="myappname">
    <CredentialResolver type="File" key="myappname-key.pem" certificate="myappname-cert.pem"/>
</ApplicationOverride>