Apache

Additional applications can be enabled on your Apache server by performing the following steps:

A. Define Additional Applications

Each additional application will need to be defined using either Apache directives within a .conf file, or in the RequestMapper section of the /etc/shibboleth/shibboleth2.xml file. It is strongly recommended that you do this via Apache directives (see Option 1 below):

<Location />
    AuthType shibboleth
    ShibRequestSetting applicationId “newsite.wisc.edu”
    ShibRequestSetting requireSession 1
    require valid-user
</Location>

<RequestMapper type="Native"> 

<RequestMap applicationId="default"> 


<Host name="sp.example.wisc.edu" /> 



<Host name="newsite.wisc.edu" applicationId="newsite.wisc.edu" /> 



</RequestMap> 

</RequestMapper>

B. ApplicationOverride

With more than one Shibboleth application on the same server, the settings in ApplicationDefaults will no longer be sufficient, since each individual application needs to communicate with the login server as a distinct entity. Because of this, you will need to enter an ApplicationOverride for each new application.  Make sure to place your ApplicationOverride immediately before the closing ApplicationDefaults tag (</ApplicationDefaults>).

Here's what the ApplicationOverride for our example would look like in its most basic form:

<ApplicationOverride id="newsite.wisc.edu" entityID="https://newsite.wisc.edu/shibboleth" />

Many configurations can be set in the ApplicationOverride. Any application-specific configurations not set here will be inherited from ApplicationDefaults. For more, see the relevant page on Internet2. The two configurations that must be set for the new application to function are:

• id must have the same value as applicationId in the Host tag from the previous section.
• entityID can be any string, but must be unique and distinct from any other entities named in the shibboleth2.xml.

C. ACS Locations

The next step is to obtain your existing application's Metadata, and manually add ACS Locations for each new application that you are adding. If the existing application is https://oldsite.wisc.edu you can cURL or wget the Metadata as follows (or download it via a web browser):

curl https://oldsite.wisc.edu/Shibboleth.sso/Metadata -o fileToBeCreated

Open the Metadata file, and locate the existing application's ACS locations:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/ECP" index="4"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML/POST" index="5"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML/Artifact" index="6"/>

After the existing ACS Locations, manually add these 4 for each new application URL and save the Metadata file:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/ECP" index="4"/>

D. Inform NetID Login Service

The final step in setting up your new application is to email the NetID Login Service at help@login.wisc.edu, including an attachment containing the Metadata that has been modified to include additional ACS Locations in the previous step. We will reply to let you know when we have installed the metadata for your application on the login server.

IIS

Additional applications can be enabled on your Windows server by performing the following steps:

A. Check ISAPI filter

You first need to confirm that Shibboleth is defined in the ISAPI filter for the new site in Windows IIS:

1. Go to the site you are enabling for Shibboleth.
2. Double-click on the Handler Mappings icon.
3. Check that a script map is listed for *.sso handlers.
4. If it is not listed, click the Add Script Map link on Actions menu on the right hand side and define the Executable path to the isapi_shib.dll.
   (For a standard 32-bit Shibboleth install, the location is: C:\opt\shibboleth-sp\lib\shibboleth\isapi_shib.dll
   For a standard 64-bit Shibboleth install, the location is: C:\opt\shibboleth-sp\lib64\shibboleth\isapi_shib.dll)
   
5. If a script map is listed for *.sso handlers already, just verify that the path to the isapi_shib.dll is correct
6. Return to the site's home page in IIS and double-click on the ISAPI Filters icon
   
7. Verify that the Shibboleth ISAPI filter is listed, and that the path to the isapi_shib.dll is correct (same path as the handler mapping above).

Now you need to add a new entry for the application in three sections of C:\opt\shibboleth-sp\etc\shibboleth\shibboleth2.xml.

B. Site ID

In the sample XML block below, the Windows IIS Site ID and the FQDN have been added for the site/application to be enabled.

<!-- The InProcess section conrains settings affecting web server modules/filters. --> 

<InProcess logger="native.logger"> 

<ISAPI normalizeRequest="true" safeHeaderNames="true"> 


<Site id="1" name="sp.example.wisc.edu"/> 

<Site id="2" name="newsite.wisc.edu" /> 

</ISAPI> 

</InProcess>

Note that the ISAPI filter is not an element that is automatically reloaded by the shibboleth2.xml file. So even after you save your changes, the new site/application will not yet be recognized by Shibboleth. You can force the ISAPI filter to reload by recycling the site's Application Pool in IIS.

C. RequestMapper

An additional Host entry is needed in the RequestMapper section, providing the name of the Host, an ApplicationOverride and the Path to any protected directories. In the sample XML block below, the FQDN has been entered for the Host name, exactly as it appears in the ISAPI section above, and the Path element to require Shibboleth authentication for the subdirectory named protected. 

The applicationId value can be any alphanumeric string. It will be used in the next section to link the Host to its ApplicationOverride.

<RequestMapper type="Native"> 

<RequestMap applicationId="default"> 


<Host name="sp.example.wisc.edu"> 

<Path name="secure" authType="shibboleth" requireSession="true" /> 

</Host> 



<Host name="newsite.wisc.edu" applicationId="newsite.wisc.edu"> 

<Path name="protected" authType="shibboleth" requireSession="true" /> 

</Host> 



</RequestMap> 

</RequestMapper>

D. ApplicationOverride

With more than one Shibboleth application on the same server, the settings in ApplicationDefaults will no longer be sufficient, since each individual application needs to communicate with the login server as a distinct entity. Because of this, you will need to enter an ApplicationOverride for each new application.  Make sure to place your ApplicationOverride immediately before the closing ApplicationDefaults tag (</ApplicationDefaults>).

Here's what the ApplicationOverride for our example would look like in its most basic form:

<ApplicationOverride id="newsite.wisc.edu" entityID="https://newsite.wisc.edu/shibboleth" />

Many configurations can be set in the ApplicationOverride. Any application-specific configurations not set here will be inherited from ApplicationDefaults. For more, see the relevant page on Internet2. The two configurations that must be set for the new application to function are:

• id must have the same value as applicationId in the Host element from the previous section.
• entityID can be any string, but must be unique and distinct from any other entities named in the shibboleth2.xml.

E. ACS Locations

The next step is to obtain your existing application's Metadata, and manually add ACS Locations for each new application that you are adding. If the existing application is https://oldsite.wisc.edu you can download the Metadata from the following URL: https://oldsite.wisc.edu/Shibboleth.sso/Metadata

Open the Metadata file, and locate the existing application's ACS locations:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML2/ECP" index="4"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML/POST" index="5"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://oldsite.wisc.edu/Shibboleth.sso/SAML/Artifact" index="6"/>

After the existing ACS Locations, manually add these 4 for each new application URL, and save the Metadata file:

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/POST" index="1"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/POST-SimpleSign" index="2"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/Artifact" index="3"/>
<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Location="https://newsite.wisc.edu/Shibboleth.sso/SAML2/ECP" index="4"/>

F. Inform NetID Login Service

The final step in setting up your new application is to email the NetID Login Service at help@login.wisc.edu, including an attachment containing the Metadata that has been modified to include additional ACS Locations in the previous step. We will reply to let you know when we have installed the metadata for your application on the login server.