Page Comparison

...

The second step is to associate the resources that make up the new application (and the associated handler path) to an applicationId content setting that matches the id you chose in the previous step. There are two ways to do this (the simple examples apply to an entire virtual host being mapped to the new application, other examples will be shown later).

<VirtualHost>
...
ServerName myapphost.example.org:443
...
## Note, if you can't apply this globally, you need to make sure
## you apply the setting to both the content/resources *and* to
## the appropriate handler path (generally /Shibboleth.sso).
<Location />
ShibRequestSetting applicationId myappname
</Location>
...
</VirtualHost>

...

Obviously the former only works on Apache, IIS requires the latter approach. Apache commands are usually safer on Apache, because using the <RequestMap> will only work safely if you turn UseCanonicalName On.

As the comment above in the example notes, you MUST make sure that the SP handlers that are used with the application override are appropriately mapped to the same application ID as the resources. The handlers and resources are a unit.

Host vs. Path

A key issue to address when establishing additional applications is whether to organize applications by virtual host or by path. The reason for using paths is basically all about the overhead of virtual hosting, primarily in terms of having the ability to register them in your DNS and because of the need for additional certificates and IP addresses in most cases involving SSL.

...