Configure a Service Provider with Multiple Web Sites (multiple entity IDs)

Last updated: May 31, 2024
Audience: IT Staff / Technical

This document describes one method to configure a Shibboleth Service Provider (SP) to protect multiple web sites hosted on a single web server. With this method, each site acts as its own logical SP and has its own entity ID.

Background

Both Apache and IIS web servers provide the means to host multiple web sites on the same server. Installation and configuration of Shibboleth for the first web site has been covered in other Service Provider support documents on this wiki. There are two methods to configure additional web sites.

With the first method, all web sites on a server operate under one entity ID and thus behave as one logical SP. Because they operate as one logical SP, Identity Providers (IdPs) will treat them all the same and it isn’t possible to have the IdP implement different policies (e.g. attribute release) for the different sites. This method takes the least amount of configuration and registration work and is appropriate in many cases. To use this method follow Configure a Service Provider with Multiple Web Sites (one entity ID).

If you need the IdPs you work with to distinguish between the sites and treat them differently for some reason, follow the instructions below. This method takes additional configuration and registration steps. In particular, an ApplicationOverride must be configured for each site and each site must be registered as a unique SP with its own entity ID.

Prerequisites

  1. You have your first web site installed, configured, and working properly with Shibboleth
  2. You have configured a second web site using one of the mechanisms supported by Apache or IIS (see your web server documentation)
  3. You have installed an appropriate certificate for SSL on the second site
  4. You have verified you can access content in the second web site over SSL before the site is configured for Shibboleth

If possible, a service provider should be configured with a single entity ID. Configuring a service provider with multiple entity IDs is not recommended unless it is necessary.

Configuration

shibboleth2.xml

In the examples used below, site1.washington.edu is the first (default) web site already configured for Shibboleth and site2.washington.edu is the second site to be configured.

  1. (IIS users only)   Add a second entry to the <ISAPI> section, where the site IDs are those listed in IIS Manager.
    <ISAPI normalizeRequest="true" safeHeaderNames="true">
        <Site id="1" name="site1.washington.edu"/>
        <Site id="2" name="site2.washington.edu"/>
    </ISAPI>
  2. (IIS users only) Add the second site to the <RequestMap> section. Note that in this example both sites will require Shibboleth only for content within the /secure directory. You can change this path as needed or require Shibboleth for the entire site. Note the applicationID="site2" parameter for the second web site. The value you set here is the link to the <ApplicationOverride> you will configure in step 4.
    <RequestMapper type="Native">
        <RequestMap>
            <!-- first web site -->
            <Host name="site1.washington.edu">
                    <Path name="secure" authType="shibboleth" requireSession="true"/>
            </Host>
            <!-- second web site -->
            <Host name="site2.washington.edu" applicationId="site2">
                    <Path name="secure" authType="shibboleth" requireSession="true"/>
            </Host>
        </RequestMap>
    </RequestMapper>
  3. Create an <ApplicationOverride> for the second web site just inside the </ApplicationDefaults> closing tag. There wouldn’t be an <ApplicationOverride> for the first web site unless you previously needed to apply non-default session management settings to specific content paths within the site. The value used in id="site2" must match the value in applicationID="site2" you configured in step 2.
    <!-- App override for second web site -->
    <ApplicationOverride id="site2" entityID="https://site2.washington.edu/shibboleth" />
  4. [Apache users only] Location or .htaccess directives can specify which application to use, for example:
    authtype shibboleth
    ShibRequestSetting applicationId site2
    shibrequiresession on
    require valid-user

Restart

  • Apache users
    1. Send a USR1 signal to the apache parent daemon
    2. Restart the shibd daemon
  • IIS users
    1. Restart the IIS process
    2. Restart the shibd daemon

Registration

As configured above, the second website will now have a metadata endpoint at https://site2.washington.edu/Shibboleth.sso/Metadata. The site metadata needs to be registered so that your Identity Providers (IdPs) know about it. If your site will be federated, request registration with InCommon. Otherwise you can register with the UW.

See Also