Retour d'expérience d'une installation Shibboleth (Fournisseur d'identités)

Ressource Plume
  • Création ou MAJ importante : 19/07/10
  • Correction mineure : 19/12/11
  • Auteur de la fiche : Samuel Godey (UREC 01/10-07/10)
  • Fiches logiciel PLUME connexes : CAS, Shibboleth, Tomcat
Mots clés

 

La fiche

Document de base pour la rédaction de cette fiche

Date : JUIN-DECEMBRE 2009
Auteur : Samuel Godey (CDD Ingénieur d'étude de 6 mois)
Commanditaire : Patrice Koch (Directeur du CRI Université de Franche-Comté à Besançon)

Nature de la fiche

Cette fiche expose mon expérience sur l'installation du serveur fournisseur d'identités à l'université de Franche-Comté en 2009 et explique comment réaliser la mise à jour des briques logicielles nécessaires à son fonctionnement. La partie fournisseur de services ne sera pas traitée. Certaines informations dans ce texte ont été volontairement remplacées par des termes génériques. La configuration décrite ici est dépendante de l'architecture déjà en place à l'université de Franche-Comté, cependant la majorité des grandes structures utilise des technologies similaires. Les paramètres peuvent varier et sont certainement incompatibles avec votre situation. N'attendez de ce texte qu'un point de départ ou une source d'inspiration pour votre propre fournisseur d'identités.
Attention : ce document ne garantie pas le bon fonctionnement de votre installation.

Public destinataire

Cette note est à l'attention des administrateurs d'un service "fournisseur d'identités" avec la technologie Shibboleth. Veuillez prendre en considération que des connaissances sur LDAP ainsi que sur le service SSO CAS sont nécessaires pour suivre cette fiche, bien que ces services ne soient pas obligatoires pour utiliser Shibboleth. Le serveur fournisseur d'identités a été ajusté pour la fédération éducation-recherche de Renater. Je considère que les utilitaires GNU/Debian sont maîtrisés.

Complément d'information

Les supports techniques utilisés pour réaliser l'installation initiale ainsi que d'autres documentations pour l'installation sont disponibles à l'adresse : https://federation.renater.fr
Les noms des programmes mentionnés dans ce document peuvent se trouver sous la forme "logiciel-x.x.x.foo". Veuillez prendre en considération la version des programmes stables à jour afin d'adapter ce document dans le temps. Par exemple, remplacez x.x.x par 2.3.1 si la version du logiciel "logiciel" est actuellement en version 2.3.1.

Fiches PLUME en lien avec ce retour d'expérience

Pré-requis

Serveur :

Application Debian non-free/contrib :

Applications Debian main :

Applications externes :

Plan

1) Introduction

1.1) Présentation des chemins d'accès
1.2) Sources des programmes

2) Procédure de mise-à-jour de la brique Shibboleth-idp

2.1) Procédure de mise-à-jour de la brique CAS-client

3) Procédure de mise-à-jour et d'installation de Tomcat
4) Configuration de Apache2.2 (lenny/debian)
5) Configuration de Shibboleth-idp

5.1) attribute-resolver.xml
5.2) attribute-filter.xml

6) Droits et sécurité

6.1) Shibboleth-idp
6.2) Tomcat
6.3) Certificat SSL Apache
6.4) Ajout des certificats non valides

1) Introduction

Veuillez considérer ce document comme un complément d'information pour un service "fournisseur d'identités" déjà en exploitation ou en test avec les briques LDAP et CAS configurées. Il est inutile d'essayer de réaliser une nouvelle installation en s'appuyant sur ce document. Si vous souhaitez installer ce service pour la première fois, il est conseillé d'utiliser les supports techniques fournis par Renater et la documentation officielle de Shibboleth :
- Support technique Renater : https://federation.renater.fr
- Documentation officielle de Shibboleth-idp : https://spaces.internet2.edu/display/SHIB2/

Dans le cas d'une mise-à-jour à cause d'un problème de sécurité ou encore parce que de nouvelles fonctionnalités sont nécessaires, il est important de conserver une copie de la configuration en cours et de procéder à une installation standard. Dès que la mise-à-jour est terminée, il faut vérifier vos fichiers de configuration et les remplacer si nécessaire par vos sauvegardes.

Remarque très importante : si vous hésitez à réaliser une mise-à-jour et que vous préférez utiliser un SNAPSHOT (point de sauvegarde instantanée) de votre machine virtuelle, vous devrez impérativement re-synchroniser l'horloge (avec ntptime) de la machine virtuelle. En effet, une petite dérive temporelle peut supprimer les sessions actives des utilisateurs. Dans le pire de cas, un redémarrage suffit est reste une valeur sûre.

1.1) Présentation des chemins d'accès

Je vous encourage à prendre en considération les chemins ci-dessous pour la lecture de ce document car je les ai déterminés arbitrairement. Par ailleurs, ces derniers peuvent ne pas être les plus judicieux. À vous de choisir des emplacements confortables.

Shibboleth-idp : /opt/shibboleth-idp
configuration de Shibboleth : /opt/shibboleth-idp/conf
certificats de Shibboleth : /opt/shibboleth-idp/credentials
méta-données (éducation-recherche) : /opt/shibboleth-idp/metadata

Données complémentaires :

fqdn shibboleth-idp : idp.mondomaine.fr
chemin source idp : /opt/shibboleth-identityprovider-x.x.x
chemin brique logicielle : /opt/shibboleth-identityprovider-x.x.x/lib/cas-client-core-x.x.x.jar
config compil : /opt/shibboleth-identityprovider-x.x.x/src/main/webapp/WEB-INF/web.xml
configuration Renater : https://services-federation.renater.fr/exemples/co...
méta-données Renater : https://services-federation.renater.fr/metadata/re...
certificat fédération Renater : https://services-federation.renater.fr/metadata/me...

Remarques :

idp.mondomaine.fr a besoin uniquement des ports 448 et 8448. Ils doivent être accessibles et sont nécessaires au bon fonctionnement du service.
À vos pare-feu : 448 et 8448 ouverts en entrée sur idp.mondomaine.fr

1.2) Sources des programmes :

shibboleth-idp url : http://shibboleth.internet2.edu/downloads/shibbole...
shibboleth-idp nom de l'archive : shibboleth-identityprovider-x.x.x-bin.zip
cas-client url : http://www.ja-sig.org/downloads/cas-clients/
cas-client nom archive : cas-client-x.x.x-release.zip
tomcat6 url : ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x...
tomcat6 nom archive : apache-tomcat-6.x.xx.tar.gz

2) Procédure de mise-à-jour de la brique Shibboleth-idp

2.1) Procédure de mise-à-jour de la brique CAS-client

3) Procédure de mise-à-jour et d'installation de Tomcat

Je tiens à préciser qu'il est impératif de fonctionner avec Tomcat en version 6 au minimum. La version 5.5 rien ne marchera pas avec la plupart des navigateurs hormis mozilla-firefox, puisqu'il y a un problème de compatibilité avec les COOKIES. Dans certain cas Tomcat6 n'est pas proposé avec les distributions stables de linux, il faut donc récupérer une version binaire pré-compilée sur le site officiel de la fédération Apache.

L'installation n'a rien de compliqué mais nécessite de prendre quelques précautions pour éviter de donner un accès global au serveur. J'indique ici comment mettre Apache2.2 en frontal de Tomcat6 avec une configuration optimale, aussi bien pour Apache2.2 que pour Tomcat6.

En résumé, Apache2.2 constitue la porte d'entrée et de sortie vers l'extérieur. Apache communique directement avec Tomcat via un proxy accessible uniquement depuis la boucle locale. Tomcat s'occupe juste d'exécuter les applications web Java (webapps). Ici il est question de "idp.war".

C'est donc Tomcat6 qui doit avoir les droits nécessaires de lecture des fichiers de configuration et d'écriture des logs de Shibboleth. De façon à soulager Tomcat, la gestion de SSL/TLS est prise en charge par Apache2.2.

Voici la procédure à suivre :

4) Configuration de Apache2.2 (Lenny/Debian)

5) Configuration de Shibboleth-idp

Il s'agit de la configuration principale et donc celle que vous devrez utiliser pour administrer Shibboleth. Elle se trouve dans deux fichiers :

- Fichier de génération d'attributs : /opt/shibboleth-idp/conf/attribute-resolver.xml

Ce fichier est nécessaire pour configurer les connecteurs, LDAP, BDD et Statique. Il sera aussi très pratique pour déterminer les attributs nécessaires aux ressources.

- Fichier de contrôle de la propagation d'attributs : /opt/shibboleth-idp/conf/attribute-filter.xml

Ce fichier détermine quels attributs seront fournis aux ressources.

Le support technique Renater offre des fichiers d'exemples qui servent de base à la fédération. Pour une utilisation classique, il faut naturellement changer la configuration des connecteurs et filtrer la propagation des attributs, le but étant d'avoir le contrôle de son fournisseur d'identités.
Fichiers de configuration d'exemples Renater : https://services-federation.renater.fr/exemples/co...

5.1) attribute-resolver.xml

Modifiez attribut-resolver.xml à partir de la section "Data connectors" comme ci-dessous :
(Ces connecteurs sont obligatoires pour mondomaine.fr)

<resolver:DataConnector id="StaticAttributes"
xsi:type="Static"
xmlns="urn:mace:shibboleth:2.0:resolver:dc">

<Attribute id="eduOrgLegalName">
<Value>
Idp MonDomaine.fr
</Value>
</Attribute>

<Attribute id="EduPersonEntitlement">
<Value>
urn:mace:dir:entitlement:common-lib-terms
</Value>
</Attribute>

</resolver:DataConnector>

<resolver:DataConnector id="votreLDAP"
xsi:type="LDAPDirectory"
xmlns:"urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://ldap.mondomaine.fr"
baseDN="ou=people,dc=mondomaine,dc=fr"
principal="cn=cri,ou=services,dc=mondomaine,dc=fr"
principalCredential="VotreMotDePasse">

<FilterTemplate>
<![CDATA[
(uid=$requestContext.princpalName)
]]>
</FilterTemplate>

</resolver:DataConnector>

<resolver:DataConnector id="computedID"
xsi:type="ComputedID"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
generatedAttributeID="computedID"
sourceAttributeID="uid"
salt="VotrePointeDeSel">

<resolver:Dependency ref="votreLDAP" />

</resolver:DataConnector>

5.2) attribute-filter.xml

Ce fichier est indispensable pour l'ajout d'un fournisseur de services. Les fournisseurs de services mentionnés dans ce fichier seront accessibles. Voici un exemple pour ajouter un fournisseur de services :

6) Droits d'accès et sécurité

Les droits d'accès peuvent être réglés avec beaucoup de souplesse. Voici un ensemble de règles pour protéger le service et les informations sensibles.

6.1) Shibboleth-idp

Shibboleth doit être accessible par Tomcat :

chown -R tomcat logs metadata credentials
chmod 755 logs metadata
chmod 750 credentials
chown tomcat conf/attribute-filter.xml
chmod 660 conf/attribute-filter.xml

chmod 444 /opt/shibboleth-idp/credentials/metadata-federation-renater.crt
chown tomcat /opt/shibboleth-idp/credentials/idp.key
chgrp root /opt/shibboleth-idp/credentials/idp.{key,crt}
chmod 440 /opt/shibboleth-idp/credentials/idp.key
chmod 644 /opt/shibboleth-idp/credentials/idp.crt

6.2) Tomcat

D'origine les droits sont bien réglés, mais assurez-vous que l'utilisateur "tomcat" est bien le propriétaire de :

/opt/tomcat

chown -R tomcat /opt/tomcat

6.3) Certificat SSL Apache

Les certificats SSL permettent d'identifier le serveur via une procédure de signature. Les échanges d'identités entre les utilisateurs et les ressources seront chiffrées. Protégez vos certificats :

chown root:root /etc/ssl/private/idp.mondomaine.fr.key
chmod 640 /etc/ssl/private/idp.mondomaine.fr.key

chown root:root /etc/ssl/certs/globalsign_ct_root.pem
chown root:root /etc/ssl/certs/idp.mondomaine.fr.pem
chown root:root /etc/ssl/certs/sureserverEDU.pem

chmod 640 /etc/ssl/certs/globalsign_ct_root.pem
chmod 640 /etc/ssl/certs/idp.mondomaine.fr.pem
chmod 640 /etc/ssl/certs/sureserverEDU.pem

 Attention Remarque : le prestataire qui assure la sécurité des certificats peut changer. Ce qui précède est donc valable jusqu'à la réception de nouveaux certificats (sauf si vous passez par GlobalSign).

Veuillez prendre note des modifications suivantes pour les nouveaux certificats.

6.4) Ajoutez des certificats non valides

Malheureusement un bon nombre d'aministrateurs n'utilise pas SSL dans les règles de l'art. Les serveurs mal administrés ne sont pas considérés comme dignes de confiance et Java ou les navigateurs internet n'accepteront pas les connexions avec ces serveurs. Pour résoudre ce problème et forcer Java à utiliser ces serveurs, vous devez ajouter manuellement les certificats dans son KeyStore de la façon suivante :