Page Comparison

...

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 might look something like this :example. Here, the goal is to establish a separate override for the content inside "/secure/apps/special". In this example the entityID is also being overridden, but that will depend on exactly why you're doing the override.

<RequestMap applicationId="default">
    <Host name="www.example.org">
        <Path name="myappfoldersecure" requireSession="true">
			<Path name="apps">
				<Path name="special" applicationId="myappname"/>example-special"/>
			</Path>
		</Path>
    </Host>
</RequestMap>
...
<ApplicationDefaults ... entityID="https://www.example.org/shibboleth">
...
    <ApplicationOverride id="myappname" entityId="https://www.example.org/special/shibboleth">
        <Sessions lifetime="28800" timeout="3600" checkAddress="false"
			handlerURL="/myappfoldersecure/apps/special/Shibboleth.sso" />
    </ApplicationOverride>
</ApplicationDefaults>

...

Luckily, you do NOT have to actually redefine all of the handler the <Sessions> element's typical child elements. Those will still be inherited, and their locations will be adjusted relative to the new handlerURL you define.

The other key here is to recognize that the handlerURL lives inside the path you set aside for this application to use. It MUST map to the corresponding applicationId, just like any other resources that make makes up the application. It's literally part of the application. If you fail to make that connection, you will typically experience looping behavior or errors involving invalid audience conditions, because the SAML assertion delivered to the incorrectly specified handlerURL will be associated with the wrong application and entityID, usually the "default" one.

...

If the application is intended to function as a new separate logical SP with its own entityID, then all of the information in the previous section still applies, but of course the endpoints would be found in a new metadata instance (<md:EntityDescriptor>) with the new entityID.

...