Search Google Appliance

Home >> Accounts >> Federation >> Using one Shibboleth Service Provider for multiple virtual hosts

Using one Shibboleth Service Provider for multiple virtual hosts

A Shibboleth Service Provider can cover multiple virtual hosts on the same server.  However, to make this work you will need to include endpoints for each virtual host in the federation's registered/published metadata for the service provider.  This is best done by modifying the metadata file downloaded from https://ssp.unit.ox.ac.uk/Shibboleth.sso/Metadata by hand. 

Editing the metadata file

Each of the following element types in the XML will need to be duplicated:

  • <init:RequestInitiator .../>
  • <idpdisc:DiscoveryResponse ... index="n"/>
  • <md:ArtifactResolutionService ... index="n"/>
  • <md:AssertionConsumerService ... index="n"/>

Note that the SingleLogoutService endpoint should not be duplicated.

In addition, any XML elements that contain an index attribute will need unique values to be assigned.  This is done per element name.  For example, if we have an SP "https://ssp.unit.ox.ac.uk/shibboleth" and wish to add a new CNAME or virtual host "ssp2.unit.ox.ac.uk", the additional elements would look like:

    <SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">
        <Extensions>
            <init:RequestInitiator Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://ssp.unit.ox.ac.uk/Shibboleth.sso/Login"/>
            <init:RequestInitiator Binding="urn:oasis:names:tc:SAML:profiles:SSO:request-init" Location="https://ssp2.unit.ox.ac.uk/Shibboleth.sso/Login"/>
            <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://ssp.unit.ox.ac.uk/Shibboleth.sso/Login" index="1"/>
            <idpdisc:DiscoveryResponse Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://ssp2.unit.ox.ac.uk/Shibboleth.sso/Login" index="2"/>
        </Extensions>

...

        <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ssp.unit.ox.ac.uk/Shibboleth.sso/SAML2/POST" index="1"/>
...
        <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://ssp.unit.ox.ac.uk/Shibboleth.sso/SAML/Artifact" index="6"/>
        <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://ssp2.unit.ox.ac.uk/Shibboleth.sso/SAML2/POST" index="7"/>
...
        <AssertionConsumerService Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://ssp2.unit.ox.ac.uk/Shibboleth.sso/SAML/Artifact" index="12"/>

 

The element ordering must be maintained for the XML to be valid, so all elements of a given type should be kept together (e.g. all <md:AssertionConsumerService /> elements).  There is no need to change the entityID in the “<EntityDescriptor />” element or the certificate, although all hostnames must be resolvable in DNS to satisfy the IAM team's policies.

Endpoint naming policy

At Oxford we will require any additional endpoints to conform to our policy on the naming of endpoints. That is:

  • All endpoints must use HTTPS URLs
  • The FQDN should be resolvable in DNS.
  • The requestor should have authority over the subdomain that the endpoint resides. e.g. They are an ITSS for the unit to which the DNS subdomain belongs.

Registering a metadata change 

The new metadata with the additional endpoints will need to be registered with the appropriate federation before it will be seen by the Oxford Identity Provider.
 
Note that metadata changes should be checked thoroughly before submitting changes for registration, especially if the entityID covers endpoints for applications that are already Live. Any errors could potentially impact the authentication for existing applications that use the same entityID e.g. If the indexing is incorrect and existing endpoints are overwritten. Don't rely on the federation operator to check this for you although they will likely spot the most obvious problems. Ideally you would plan some service downtime for testing after you have been notified that the change is registered although asking for the change to be backed out in an emergency may not happen as quickly as you would like.
 
For Service Providers registered with the UK Federation the Admin contact for that SP can send the metadata directly to the UK Federation, or alternatively the IAM team who will check & submit the change request to the UK Federation. 
 
For Service Providers registered with the Oxford Internal Federation please send the new metadata file to the IAM team, who will update the Internal Federation with the new metadata.

Written by IT Services. Latest revision 6 June 2018