Pages enfant
  • Shibboleth (esup 4)

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

Bloc de code
languagehtml/xml
titleetc/shibboleth/shibboleth2.xml
<ApplicationDefaults entityID="https://<IdP>/Shibboleth.sso<entityID du SP>"
                         REMOTE_USER="uid eppn persistent-id targeted-id">

 

Le tutoriel de la féderation Renater détaille ici certains éléments de configuration du SP, notamment les paramètres du nœud ApplicationDefaults. Parmi ceux-ci, le paramètre SSO (ancien SessionInitiator) va notamment permettre de définir la façon dont Shibboleth gère les demandes de session.

Par exemple, en définissant la balise de la façon suivante :

Bloc de code
languagehtml/xml
titleetc/shibboleth2.xml
<SSO discoveryProtocol="SAMLDS" discoveryURL="https://services-federation.renater.fr/test/wayf">
    SAML2 SAML1
</SSO>

Ici, le SP va utiliser un procole SAMLDS (Discovery Service), qui se fera via le WAYF précisé, pour l'identification. Le protocole SAML2 sera utilisé en priorité, et s'il n'est pas supporté, c'est SAML1 qui le sera.
Plus d'informations sur les valeurs possibles pour ce paramètre sont détaillées sur le wiki Shibboleth.

Il est également possible de filtrer dans ce fichier de configuration les IdP qui auront (whitelist) ou n'auront pas (blacklist) accès à l'application. La fédération Renater décrit ici la configuration à adopter.

Configuration uPortal

Une fois le serveur frontal configuré avec le SP, il faut configurer uPortal pour l'authentification via Shibboleth. L'authentification se fait par REMOTE_USER : l'utilisateur est identifié par Shibboleth, et est transmis à uPortal. Il va donc falloir faire les changements nécessaires.

...