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.
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://pub.federation.renater.fr/metadata/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://pub.federation.renater.fr/metadata/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.
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.