Skip to Content

Shibboleth SP in multidomain environment

Multidomain Environment

The Shibboleth SP can be used in a multi-domain environment, this is particularly relevant in a shared web-hosting scenario where a number of webapps for different domains/clients will have different Shibboleth configuration using the same instance of Shibboleth (running on on one host). The example below shows how this configuration can be achieved, it should be read in conjunction with the single-domain Shibboleth Service Provider Installation Guide
which covers the basics of installaing the software and explains some of the configuration parameters which are not expanded upon herein.
Let's presume we have set one service called: library.example.com and it's protected by shibboleth and in the production Edugate federation. Now we want protect another on called maths.example.com which is on the same host and part of the test Edugate federation.

Shibboleth configuration

You need to create new certificate and key for shibboleth (not Apache), in this example they will be named maths-example-com-key.pem and maths-example-com-cert.pem. The certificates and keys must be configured within shibboleth2.xml file for for each multidomain SP as follows; Firstly copy the piece of code

<ApplicationDefaults ...>
....
....
</ApplicationDefaults>

replace ApplicationDefaults with ApplicationOverride and paste in just before

</ApplicationDefaults>

You then need to modify this part of code. It is very important to define settings specific to the maths.example.com domain inside <ApplicationOverride > and </ApplicationOverride >
For example;

<ApplicationOverride id="maths-example-com" 
         entityID="https://maths.example.com/shiboleth"
         REMOTE_USER="eppn"
         signing="false" encryption="false">
       <Sessions lifetime="28800" timeout="3600" checkAddress="false"
           handlerURL="/Shibboleth.sso" handlerSSL="false"
           exportLocation="http://localhost/Shibboleth.sso/GetAssertion" 
           exportACL="127.0.0.1"
           idpHistory="false" idpHistoryDays="7">

          <!-- Default example directs to a specific 
              IdP's SSO service (favoring SAML 2 over Shib 1). -->
          <SessionInitiator type="Chaining" Location="/Login"  id="Intranet"
                   relayState="cookie"
                   entityID="https://defaul-idp.example.com/idp/shibboleth">
              <SessionInitiator type="SAML2" acsIndex="1" 
                       template="bindingTemplate.html"/>
              <SessionInitiator type="Shib1" acsIndex="5"/>
          </SessionInitiator>

          <!-- An example using an old-style WAYF, which means Shib 1 only
                  unless an entityID is provided. -->
          <SessionInitiator type="Chaining" Location="/WAYF" id="WAYF"
                  relayState="cookie">
              <SessionInitiator type="SAML2" acsIndex="1"
                      template="bindingTemplate.html"/>
              <SessionInitiator type="Shib1" acsIndex="5"/>
              <SessionInitiator type="WAYF" acsIndex="5"
                      URL="https://wayf.example.org/WAYF"/>
          </SessionInitiator>

          <!-- example supporting the new-style of discovery service. -->
          <SessionInitiator type="Chaining" Location="/DS" id="DS"
                  isDefault="true" relayState="cookie">
              <SessionInitiator type="SAML2" acsIndex="1"
                      template="bindingTemplate.html"/>
              <SessionInitiator type="Shib1" acsIndex="5"/>
              <SessionInitiator type="SAMLDS"
                      URL="https://wayf-test.heanet.ie/WAYF/WAYF"/>
          </SessionInitiator>

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

          <!-- LogoutInitiators enable SP-initiated local or global/single logout of sessions. -->
          <LogoutInitiator type="Chaining" Location="/Logout" relayState="cookie">
              <LogoutInitiator type="SAML2" template="bindingTemplate.html"/>
              <LogoutInitiator type="Local"/>
          </LogoutInitiator>

          <!-- md:SingleLogoutService locations handle single logout (SLO) protocol messages. -->
          <md:SingleLogoutService Location="/SLO/SOAP"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
          <md:SingleLogoutService Location="/SLO/Redirect" conf:template="bindingTemplate.html"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
          <md:SingleLogoutService Location="/SLO/POST" conf:template="bindingTemplate.html"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
          <md:SingleLogoutService Location="/SLO/Artifact" conf:template="bindingTemplate.html"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
       <!-- md:ManageNameIDService locations handle NameID management (NIM) protocol messages. -->
          <md:ManageNameIDService Location="/NIM/SOAP"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>
          <md:ManageNameIDService Location="/NIM/Redirect" conf:template="bindingTemplate.html"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect"/>
          <md:ManageNameIDService Location="/NIM/POST" conf:template="bindingTemplate.html"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"/>
          <md:ManageNameIDService Location="/NIM/Artifact" conf:template="bindingTemplate.html"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"/>
          <!--
          md:ArtifactResolutionService locations resolve artifacts issued when using the
           SAML 2.0 HTTP-Artifact binding on outgoing messages, generally uses SOAP.
          -->
          <md:ArtifactResolutionService Location="/Artifact/SOAP" index="1"
              Binding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP"/>

          <!-- Extension service that generates "approximate" metadata based on SP configuration. -->
          <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>

          <!-- Status reporting service. -->
          <Handler type="Status" Location="/Status" acl="127.0.0.1"/>

          <!-- Session diagnostic service. -->
          <Handler type="Session" Location="/Session" showAttributeValues="false"/>

      </Sessions>
          <!-- List of metadata locations which contain trusted Idps. This is just example -->
      <MetadataProvider type="Chaining">
          <!-- Example of remotely supplied batch of signed metadata. -->
          <!--
          <MetadataProvider type="XML" uri="http://edugate-test.heanet.ie/edugate-test-metadata-signed.xml"
               backingFilePath="federation-metadata.xml" reloadInterval="7200">
             <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
             <MetadataFilter type="Signature" certificate="fedsigner.pem"/ >
          </MetadataProvider>
          -- >
      <AttributeFilter type="XML" validate="true" 
                 path="maths-incoming-attribute-policy-.xml"/>
      <CredentialResolver type="File" key="maths-example-com-key.pem" 
                 certificate="maths-example-com-cert.pem"/>

      </ApplicationOverride>

Note: usually you only need copy parts which you want to change, see the the configuration for the library.example.com which has a different entityID, federation metadata, different policy on signing and encrypting SAML messages and different certificates for signing and encryption. It also has longer session and metadata lifetimes;

<ApplicationOverride id="library-example-com" 
         entityID="https://library.example.com/shiboleth"
         REMOTE_USER="email"
         signing="true" encryption="false">
       	<Sessions lifetime="80000" timeout="36000" checkAddress="false"
           handlerURL="/Shibboleth.sso" handlerSSL="false"
           exportLocation="http://localhost/Shibboleth.sso/GetAssertion" 
           exportACL="127.0.0.1"
           idpHistory="false" idpHistoryDays="7">
	
           <SessionInitiator type="Chaining" Location="/DS" id="DS"
                  isDefault="true" relayState="cookie">
              <SessionInitiator type="SAML2" acsIndex="1"
                      template="bindingTemplate.html"/>
              <SessionInitiator type="Shib1" acsIndex="5"/>
              <SessionInitiator type="SAMLDS"
                      URL="https://wayf.heanet.ie/WAYF/WAYF"/>
          </SessionInitiator>
	</Sessions>
          
	<MetadataProvider type="XML" uri="https://edugate.heanet.ie/edugate-federation-metadata-signed.xml"
               backingFilePath="libraryt-federation-metadata.xml" reloadInterval="72000">
             <MetadataFilter type="RequireValidUntil" maxValidityInterval="2419200"/>
             <MetadataFilter type="Signature" certificate="fedsigner.pem"/ >
          </MetadataProvider
      <AttributeFilter type="XML" validate="true" 
                 path="library-incoming-attribute-policy.xml"/>
      <CredentialResolver type="File" key="library-example-com-key.pem" 
                 certificate="library-example-com-cert.pem"/>

</ApplicationOverride>

Any changes made to the Shibboleth2.xml file can be checked for errors as follows;

/usr/sbin/shibd -t /etc/shibboleth/shibboleth2.xml

Apache configuration
You need to set which part of shibboleth configuration will be used by specific virtualhost.
As you see your new configuration has id="maths-example-com" so to load this configuration you need add below code into (apache) maths.example.com virtualhost

ShibRequestSetting applicationId maths-example-com

The library application, which will require Shibboleth authentication for the entire library.example.com domain rather than specifific Location's, would be configured as follows

ShibRequestSetting applicationId library-example-com
ShibRequireSession On

Note: If ShibRequestSetting is not set in VirtualHost then default (ApplicationDefault id="default") shibboleth config is used.

Who is Edugate for?

Edugate provides a single access mechanism that can enable access to online resources supporting alliances, research collaboration, consortia and shared services. Now users can use the credentials issued by their institution to access Edugate enabled web-sites and benefit from a personalised and persistent experience, with privacy features that put the user in control.

Enable users to use the campus directory credential to access Edugate enabled web sites beyond the campus boundary from anywhere, whilst protecting the campus directory from unnecessary searches and the user credentials from use on web sites beyond your control. 
 

Your patrons are individuals, not IP Addresses!
 
Enable publishers to provide users with a consistent and personalised experience regardless of their location or the device they are using.
Improve the end-user experience by providing Single-Sign-On and reducing the frequency of prompts for campus credentials.
Connect your patrons to your subscribed resources, regardless of where the user performs their search.

Restrict access to your club or society web-site to valid campus users without needing the campus IT department to provide you with access to the entire campus user database.
For student unions, Edugate enables online elections that can authenticate all students currently enrolled without needing to expose campus credentials or personal information.

Example: UL Students Union

Provide your suppliers with a means to interact with all campus members. Whether its parking management, physical access management, catering or sports facilities, Edugate can provide a secure means to validate staff and student status. Access cards or tokens can be issued online in a self-service manner, removing the some, if not all, of the paperwork.

Example: Apcoa Parking Management

When establishing any online service that will be used by multiple institutions, Edugate will provide a means to authorise access to the service by user, role or institution without having to issue usernames/passwords or other credentials to the users of the service.
Most research projects are collaborations and when it comes to hosting collaborative tools or sharing documents and data, Edugate enables the hosting partner to seamlessly grant access to the project content.

Example: NDLR Repository
Example: HEAR and DARE

Campus IT managers and IT security officers are increasingly reluctant to synchronise user credentials or open up campus directory services to applications that are hosted in the cloud. Even locally hosted managed applications that require the campus credential to be processed by the application present a security risk. Edugate is built on the open SAML federated access standard that is used in the financial services, aerospace and governmant eID and provides Single-Sign-On without the risks.

e-Government
Whether it's a central or local government service that needs to validate that a student is a current student, Edugate can open up the potential for numerous e-Government services for students (e.g. Grants and Tax Credits)

e-Commerce
When offering a student discount online, relying on a campus email address leaves the offer open to abuse since many institutions offer 'email for life'. Edugate will allow you to know if a customer is a current student and which institution the customer is affiliated to.