Page en cours de construction. Les informations présentes peuvent présenter de légères erreurs

Configurer un SP pour 2 domaines DNS différents

Le logiciel Service Provider Shibboleth permet de gérer plusieurs contextes applicatifs, correspondant éventuellement à plusieurs domaines DNS, avec une même instance du logiciel.

Nous allons dérouler un exemple où le SP Shibboleth protège deux applications :

Documentation de référence :

1. Configuration des contextes applicatifs

Les éléments de configuration ApplicationDefaults et ApplicationOverride du fichier shibboleth2.xml permettent de définir des contextes applicatifs. En effet, plusieurs applications peuvent utiliser le même contexte applicatif Shibboleth. Concrètement vous devez créer autant de contextes applicatifs que vous avez de groupes d'applications qui partagent les éléments suivants :

  • les mêmes méta-données de fédération
  • les mêmes règles d'accès (limitation des IDPs, Timeouts…)

Il est recommandé de n'utiliser le niveau ApplicationDefaults que pour définir des défauts (méta-données, session initiators, profiles supportés, etc) communs à tous les contextes applicatifs ; ainsi vous gardez cette couche comme conteneur de défauts.

    <ApplicationDefaults id="default" policyId="default"
        entityID="https://main.mondomaine/noapp"
        homeURL="https://main.mondomaine/noapp"
        REMOTE_USER="mail eppn persistent-id targeted-id"
        signing="false" encryption="false">
	....
        <!-- Ici on peut définir des ApplicationOverride -->
 
    </ApplicationDefaults>

Chaque élément ApplicationOverride peut redéfinir certains éléments de l'ApplicationDefaults. L'élément id est un identifiant interne au fichier de configuration, utilisé pour le routage (voir plus bas). L'élément entityID correspond à l'identifiant de la ressource, telle que publiée dans les méta-données.

Depuis le SP Shibboleth 3, il n'est plus nécessaire de déclarer autant d'ApplicationOverride que d'entityId, lorsqu'on utilise apache.
En effet, l'entityID peut être déclaré au niveau de la configuration Apache. Ce qui est à la fois plus concis et simplifie la configuration Sibboleth SP.
Les éléments importants pouvant être déportés au niveau d'Apache sont :
  • entityId
  • URL du WAYF

La liste complète est disponible ici :
https://wiki.shibboleth.net/confluence/display/SP3/ContentSettings


Dans l'exemple ci-dessous, nous déclarons 2 ApplicationOverride dans le fichier shibboleth2.xml :

  • Un pouvant être utilisé par les applcations utilisant la fédération de test
  • Un pouvant être utilisé par les applcations utilisant la fédération Éducation-Recherche
  <ApplicationOverride id="test" REMOTE_USER="eppn persistent-id targeted-id">
      <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
          checkAddress="false" consistentAddress="false"
          handlerSSL="true" cookieProps="https">
          <SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.renater.fr/test/WAYF?cru=no">SAML2 SAML1</SSO>
      </Sessions>
      <MetadataProvider type="XML"
          url="https://metadata.federation.renater.fr/test/preview/preview-idps-renater-test-metadata.xml"
          backingFilePath="/var/cache/shibboleth/preview-idps-renater-test-metadata.xml"
          reloadInterval="3600">
          <MetadataFilter type="Signature" certificate="renater-metadata-signing-cert-2016.pem"/>
      </MetadataProvider>
  </ApplicationOverride>
 
  <ApplicationOverride id="renater" REMOTE_USER="eppn persistent-id targeted-id">
      <Sessions lifetime="28800" timeout="3600" relayState="ss:mem"
          checkAddress="false" consistentAddress="false"
          handlerSSL="true" cookieProps="https">
          <SSO discoveryProtocol="SAMLDS" discoveryURL="https://discovery.renater.fr/renater/WAYF?cru=no">SAML2 SAML1</SSO>
      </Sessions>
      <MetadataProvider type="XML"
          url="https://metadata.federation.renater.fr/renater/main/main-idps-renater-metadata.xml"
          backingFilePath="/var/cache/shibboleth/main-idps-renater-metadata.xml"
          reloadInterval="3600">
          <MetadataFilter type="Signature" certificate="renater-metadata-signing-cert-2016.pem"/>
      </MetadataProvider>
  </ApplicationOverride>

Dans l'exemple ci-dessus les deux contextes applicatifs ne sont pas du tout déclarés dans shibboleth2.xml
Cela constitue une grande amélioration dans la maintenabilité de la configuration Shibboleth SP.

2. Routage vers le bon contexte applicatif

Nous avons créé les deux contextes applicatifs ; reste à définir le routage vers ces deux contextes, en fonction de l'URL accédée. On peut définir ce routage à deux endroits : dans le fichier shibboleth2.xml ou bien dans la configuration Apache.

C'est la seconde méthode (directive ShibApplicationID dans la configuration Apache) qui est recommandée par les auteurs de Shibboleth ; elle minimise les risques d'erreurs et évite d'éditer le fichier de configuration de Shibboleth. C'est donc cette méthode qui est décrite dans cette documentation.

2.1 La méthode RequestMapper

La documentation relative à ce mode de configuration est disponible ici : https://wiki.shibboleth.net/confluence/display/SP3/XMLRequestMapper

2.2 La méthode ShibApplicationID

Ci-dessous un extrait de configuration Apache :

<!-- Configuration pour le premier vhost -->
<VirtualHost>
...
  ServerName test-application.domaine:443
...
  <Location />
    ShibRequestSetting applicationId test
    ShibRequestSetting requireSession On # Ou "Off" si Lazy
    # Déclaration de l'entityId
    ShibRequestSetting entityIDSelf https://test-application.domaine/
    # Surcharge éventuelle pour pointer sur un WAYF différent
    #ShibRequestSetting discoveryURL https://test-discovery.domaine
    ShibUseHeaders On
    Require shib-session # Ou "shibboleth" si Lazy
  </Location>
  # Permet de retourner les bonnes metadonnées si on interroge https://test-application.domaine/Shibbboleth.sso/Metadata
  <Location /Shibboleth.sso>
    SetHandler shib
  </Location>
...
</VirtualHost>
 
<!-- Configuration pour le second vhost -->
<VirtualHost>
...
  ServerName application.domaine:443
...
  <Location />
    ShibRequestSetting applicationId test
    ShibRequestSetting requireSession On # Ou "Off" si Lazy
    # Déclaration de l'entityId
    ShibRequestSetting entityIDSelf https://application.domaine/
    # Surcharge éventuelle pour pointer sur un WAYF différent
    #ShibRequestSetting discoveryURL https://discovery.domaine
    ShibUseHeaders On
    Require shib-session # Ou "shibboleth" si Lazy
  </Location>
  # Permet de retourner les bonnes metadonnées si on interroge https://application.domaine/Shibbboleth.sso/Metadata
  <Location /Shibboleth.sso>
    SetHandler shib
  </Location>
...
</VirtualHost>

La valeur de l'attribut ShibApplicationID (pour Shibboleth 1.3) ou ShibRequestSetting applicationId (pour Shibboleth 2.x et 3.x) fait référence à un contexte applicatif défini dans le fichier shibboleth2.xml.