Configure a Service Provider with Multiple Web Sites (one entity ID)

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

This document describes a method to configure a Shibboleth Service Provider (SP) to protect multiple web sites hosted on a single web server. With this method, each site is part of a single logical SP operating under one entity ID.  Use this document if all of your websites will use the same authentication configuration.  If you need Shibboleth to distinguish between the sites and treat them differently, follow Configure a Service Provider with Multiple Web Sites (multiple entity IDs) instead.

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, covered here, 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.

 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

Configuration

Make the following changes in 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:

Configuration Steps

  1. 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. Next, 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
    <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">
                    <Path name="secure" authType="shibboleth" requireSession="true"/>
            </Host>
        </RequestMap>
    </RequestMapper>
  3. Once changes have been made in shibboleth2.xml, restart the web server and shibboleth daemon:
    • Restart the IIS process
    • Restart the shibd daemon

  1. Location or   .htaccess   directives can require a Shibboleth session:
    authtype shibboleth
    shibrequiresession on
    require valid-user
  2. Once changes have been made in shibboleth2.xml, restart the web server and shibboleth daemon:
    • Send a USR1 signal to the apache parent daemon
    • Restart the shibd daemon

Registration

As configured above, the second website will now have Assertion Consumer Service endpoints under https://site2.washington.edu/Shibboleth.sso/ . These endpoints need to be registered so that your Identity Providers (IdPs) know about them. If your site will be federated, request registration with InCommon. Otherwise you can register with the UW.

The following example illustrates the Assertion Consumer Service endpoints for an SP that is only using the SAML2 HTTP-POST binding. If you have multiple bindings for site1, clone each of these for site2, updating “site1” to “site2” in each new endpoint you add.

Binding
Endpoint
Status
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST https://site1.washington.edu/Shibboleth.sso/SAML2/POST Pre-existing
urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST https://site2.washington.edu/Shibboleth.sso/SAML2/POST Need to add

 

See Also

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