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

Fiche ressource Article, événement, site web...
  • Création ou MAJ importante : 19/07/10
  • Correction mineure : 19/12/11
Mots-clés

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

  • Type de ressource : article, compte-rendu
  • Date de publication du document ou de l'événement : Septembre 2009
  • Auteur(s) ou responsable(s) : Samuel Godey (CNRS/UREC)
  • Contact pour plus d'informations : samuel.godey@urec.cnrs.fr

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 :

  • Lenny/Debian/GNU/Linux

Application Debian non-free/contrib :

  • sun-java-6

Applications Debian main :

  • Apache 2.2
  • mod_ssl
  • mod_proxy_ajp
  • OpenSSL
  • NTP-server
  • Maven

Applications externes :

  • Apache-tomcat6
  • Shibboleth-idp
  • CAS-client

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

  • Arrêtez shibboleth-idp :

    /etc/init.d/tomcat stop
  • Faites une copie de sécurité de la configuration :

    tar zcvf ~/shib-conf.tgz /opt/shibboleth-idp/conf
  • Téléchargez la dernière version :

  • Décompressez :

    jar -xf shibboleth-identityprovider-2.1.5-bin.zip
  • Éditez le fichier de compilation :

    Par commodité, je vous conseille de faire des copies de sécurité de la configuration d'accès à votre serveur CAS. À chaque nouvelle version de Shibboleth, vous devrez adapter le fichier de compilation "web.xml" avec votre système d'authentification. Le but est d'intégrer la brique "cas-client" pré-configurée sur votre réseau en ajoutant les informations locales de votre service.

    Exemple d'un fichier /opt/shibboleth-idp/cas_web.xml à adapter suivant vos besoins :

    <!-- CAS Filter Configuration -->
    <context-param>
    <param-name<serverName</param-name>
    <param-value>https://idp.mondomaine.fr</param-value>
    </context-param>
    <!-- CAS Authentication Filter -->
    <filter>
    <filter-name>CAS Authentication Filter</filter-name>
    <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class>
    <init-param>
    <param-name>casServerLoginUrl</param-name>
    <!-- votre page de login -->
    <param-value>https://cas.mondomaine.fr/cas/login</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas/login</param-value> -->
    </init-param>
    </filter>
    <!-- CAS Validation Filter -->
    <filter>
    <filter-name>CAS Validation Filter</filter-name>
    <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class>
    <init-param>
    <param-name>casServerUrlPrefix</param-name>
    <!-- Votre page de réception de ticket -->
    <param-value>https://cas.mondomaine.fr/cas</param-value>
    <!-- <param-value>https://federation.cru.fr/sac-cas</param-value> -->
    </init-param>
    </filter>
    <!-- CAS HttpServletRequest Wrapper Filter -->
    <filter>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class>
    </filter>
    <!-- CAS Assertion Thread Local Filter -->
    <filter>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <filter-class>org.jasig.cas.client.util.AssertionThreadLocalFilter</filter-class>
    </filter>
    <!-- CAS Filter for Shibb RemoteUser -->
    <filter-mapping>
    <filter-name>CAS Authentication Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Validation Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>>
    <filter-mapping>
    <filter-name>CAS HttpServletRequest Wrapper Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>
    <filter-mapping>
    <filter-name>CAS Assertion Thread Local Filter</filter-name>
    <url-pattern>/Authn/RemoteUser</url-pattern>
    </filter-mapping>

    C'est dans le fichier : /opt/shibboleth-identityprovider-2.x.x/src/main/webapp/WEB-INF/web.xml
    que vous devez reporter : /opt/shibboleth-idp/cas_web.xml. Pour ce faire, ajoutez le contenu du fichier "/opt/shibboleth-idp/cas_web.xml" juste en dessous de "</listener>"

  • Copiez le client CAS dans les bibliothèques des sources de Shibboleth :

    cp /opt/cas-client-3.x.x/modules/cas-client-core-3.x.x.jar /opt/shibboleth-identityprovider-2.x.x/lib/
  • Lancez la procédure d'installation :

    cd shibboleth-identitypovider-2.x.x
    chmod +x install.sh
    ./install.sh
  • Faites le choix d'installation :

    Where should the Shibboleth Identity Provider
    software be installed ? [/opt/shibboleth-idp]
    [Acceptez ce choix] the directory '/opt/shibboleth-idp' already exists.
    Would you like to overwrite this shibboleth configuration ?
    (yes, [no]) no => Naturellement c'est "no"

    C'est maintenant terminé, vous devez avoir en bas de votre terminal un message du type :

    BUILD SUCCESFUL
    Total time : 8 seconds
  • Synchronisez l'horloge :

    ntptime
  • Vérifiez la date :

    date
  • Relancez Shibboleth :

    /etc/init.d/tomcat start
  • Contrôlez le bon fonctionnement :

    tail -f /opt/shibboleth-idp/logs/idp-process.log

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

  • Téléchargez l'achive :

    wget http://www.ja-sig.org/downloads/cas-clients/cas-cl... -O /opt/cas-client-3.1.10-release.zip
  • Décompressez :

    cd /opt
    jar -xf cas-client-3.x.x-release.zip
  • Déplacez vous dans le répertoire :

    cd cas-client-3.x.x/cas-client-core
  • Compilez :
    mvn package
    /!\ Si vous avez une erreur => "Failed to resolve artifact"
    à propos du JAR org.opensaml:opensaml:jar:1.1b
    => Utilisez la version demandée ici 1.1b
  • Déplacez-vous ici :

  • Retournez dans le repertoire cas-client :

    cd cas-client-3.x.x/cas-client-core
  • Compilez avec la commande :

    mvn install :install-file -DgroupId=org.opensaml -DartifactId=opensaml -Dversion=1.1b\
    -Dpackaging=jar -Dfile=/opt/opensaml-1.1b.jar
  • Maintenant vous devez obtenir :

    "BUILD SUCCESSFUL"

    en bas de votre écran.

    Attention l'idp n'aura aucune connaissance de cette nouvelle version de CAS-client. Pour prendre en compte cette mise-à-jour vous devez faire l'upgrade de votre idp, cf. le paragraphe 2) Procédure de mise à jour de la brique Shibboleth-idp.

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 :

  • Emplacement de réception :

    cd /opt/
  • Récupérez l'archive "

    wget ftp://ftp.inria.fr/pub/Apache/tomcat/tomcat-6/v6.x... -O /opt/apache-tomcat-6.x.xx.tar.gz
  • Décompressez l'archive :

    cd /opt
    tar zxvf apache-tomcat-6.x.xx.tar.gz
  • Supprimez les binaires et scripts pour windows :

    cd apache-tomcat-6.x.xx
    rm bin/*.exe bin/*.bat
  • Créez un lien symbolique par commodité :

    cd /opt
    ln -s /opt/apache-tomcat-6.x.xx tomcat
  • Activez le connecteur PROXY AJP pour Tomcat :

    Ajoutez à la section <Service name="Catalina"> du fichier /opt/tomcat/conf/server.xml le connecteur comme ci-dessous :

    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
  • Commentez le connecteur sur le port 8080 dans le fichier /opt/tomcat/conf/server.xml :

    <!--
    <Connector executor="tomcatThreadPool"
    port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />
    -->
  • Supprimez les webapps de base offerts avec Tomcat :

    rm -rf /opt/tomcat/webapps/*
  • Ajoutez la webapp Shibboleth-idp dans le fichier /opt/tomcat/conf/Catalina/localhost/idp.xml

    <Context
    docBase="/opt/shibboleth-idp/war/idp.war"
    privileged="true"
    antiRessourceLocking="false"
    antiJARLocking="false"
    unpackWAR="false" />

    Remarque : vous pouvez ajouter l'attribut autoDeploy="true". Dans ce cas l'application sera chargée au lancement de Tomcat.

  • Par mesure de sécurité, supprimez les utilisateurs qui peuvent s'authentifier sur Tomcat :

    Retirez simplement le contenu de l'instance : tomcat-users dans le fichier /opt/tomcat/conf/tomcat-users.xml comme ci-dessous :

    <?xml version="1.1" encoding='utf-8 ?>
    <tomcat-users>
    </tomcat-users>
  • Lancez Tomcat au démarrage :

    Aucun script "System V" n'est fourni avec la distribution de Tomcat. Vous allez donc devoir en créer un. Par ailleurs ce procédé permet de simplifier la maintenance, mais aussi d'assurer le lancement automatique de Tomcat au démarrage du serveur. Cela permet aussi d'en profiter pour initialiser les variables d'environnement.

    Créez le fichier /etc/init.d/tomcat comme ci-dessous :

    #!/bin/sh

    RETVAL=$?
    JAVA_HOME=/usr/lib/jvm/java-6-sun
    JAVA_OPTS="-Xmx1000m -XX:MacPermSize=512m"
    CATALINA_HOME=/opt/tomcat
    IDP_HOME=/opt/shibboleth-idp

    export JAVA_HOME
    export JAVA_OPTS
    export CATALINA_HOME
    export IDP_HOME

    case "$1" in
    start)
    if [ -f $CATALINA_HOME/bin/startup.sh ];
    then
    echo $"Starting Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/startup.sh
    fi
    ;;
    stop)
    if [ -f $CATALINA_HOME/bin/shutdown.sh ];
    then
    echo $"Stoping Tomcat"
    /bin/su -p -s /bin/sh tomcat $CATALINA_HOME/bin/shutdown.sh
    fi
    ;;
    *)
    echo $"Usage: $0 {start|stop}"
    exit 1
    ;;

    exit $RETVAL

    Maintenant il ne reste plus qu'à positionner le script dans les differents niveaux de démarrage comme ci-dessous :

    chmod 755 /etc/init.d/tomcat
    update-rc.d tomcat default
  • Lancez Tomcat avec un utilisateur spécifique :

    Il est préférable de lancer Tomcat avec un utilisateur spécifique avec des privilèges limités. Le script suivant vous aidera à le créer :

    #!/bin/sh

    if ! id tomcat > /dev/null 2>&1 ; then
    adduser --system --home /opt/tomcat --no-create-home \
    --ingroup nogroup --disable-password --shell /bin/false \
    tomcat
    fi

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

  • Activez les ports d'écoute dans le fichier :

    /etc/apache2/ports.conf

    Vérifiez que Apache écoute bien les deux ports comme ci-dessous :

    Listen 443
    Listen 8443
  • Configurez vos deux accès :

    - Créez le fichier /etc/apache2/sites-available/idp ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:443>
    ServerName idp.mondomaine.fr:443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /etc/ssl/certs/idp.mondomaine.fr.pem
    SSLCertificateKeyFile /etc/ssl/private/idp.mondomaine.fr.key
    SSLCertificateChainFile /etc/ssl/certs/globalsign_ct_root.pem
    SSLCACertificateFile /etc/ssl/certss/sureserverEDU.pem
    SSLOptions +StdEnvVars

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all

    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

    - Créez le fichier /etc/apache2/sites-available/idp-aa ci-dessous :

    <IfModule mod_ssl.c>
    <VirtualHost _default_:8443>
    ServerName idp.mondomaine.fr:8443
    SSLEngine On
    SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:!SSLv2:+EXP
    SSLProtocol all -SSLv2
    SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt
    SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key
    SSLVerifyDepth 10
    SSLOptions -StdEnvVars +ExportCertData

    SetEnvIf User-Agent "*.MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    <IfModule mod_proxy_ajp.c>
    ProxyRequests Off
    <proxy ajp://localhost:8009>
    Allow from all
    </proxy>
    ProxyPass /idp ajp://localhost:8009/idp retry=5
    </IfModule>
    </VirtualHost>
    </IfModule>

  • Activez les deux accès :

    a2ensite idp idp-aa
  • Activez le module ssl :

    a2enmod ssl
  • Activez le module proxy_ajp :

    a2enmod proxy_ajp
  • Relancez le server Apache2:

    apache2ctl -t
    apache2ctl -k restart

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 :

  • Déplacez vous dans la partie suivante :

    <AttributeFilterPolicy id="releaseAttributesToSelectedSP">
  • Ajoutez le fournisseur dans "PolicyRequirementRule" :

    <PolicyRequirementRule xsi:type="basic:OR">
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_a" />
    <basic:Rule xsi:type="basic:AttributeRequesterString" value="url_fournisseur_b" />

    <!-- Mettez à la suite les fournisseurs de services -->
    <!-- Remplacez url_fournisseur_a par l'url de votre fournisseur
    exemple http://www.cairn.info
    -->
    </PolicyRequirementRule>

  • Les paramètes suivants sont les attributs propagés aux fournisseurs url_fournisseur_x :

    <!-- Ex nom complet sans accent d'une personne -->
    <AttributeRule attributeID="commonName">
    <PermitValue xsi:type="basic:ANY" />
    </AttributeRule>

    <!-- Ex nom complet avec accents -->
    <AttributeRule attributeID="DisplayName">
    <PermitValueRule xsi:type="basic:ANY" />
    </AttributeRule>

  •  Attention Pour que vos modifications soient appliquées il faut impérativement relancer Tomcat.
    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

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.

  • Afin de simplifier la gestion des certificats, réalisez un document.cnf : /etc/ssl/idp.mondomaine.cnf. Ce document permet de conserver les paramètres utilisés lors de la création du certificat requête.

    Ci-dessous son contenu :

    [req]
    default_bits = 1024
    default_keyfile = idp.mondomaine.fr.key
    distinguished_name = req_distinguished_name
    prompt = no

    [ req_distinguished_name ]
    C = FR
    O = Mon Etablissement
    CN = idp.mondomaine.fr
    emailAddress = idpmaster [at] mondomaine [dot] fr

  • Maintenant si vous voulez générer un certificat requête avec votre clé privée correspondante, vous pouvez utiliser le script ci-dessous (fichier /root/bin/req) :

    #!/bin/sh
    # Fourni dans le répertoire courant :
    # la clé (pour Apache)
    # idp.mondomaine.fr.key
    # le certificat requête (pour votre RSSI)
    # idp.mondomaine.fr_req.pem
    openssl req -new -nodes -out idp.mondomaine.fr_req.pem\
    -config /etc/ssl/idp.mondomaine.fr.cnf

  • Vous devez remplacer la clé "RSA PRIVATE KEY" par la nouvelle clé :

    cat ./idp.mondomaine.fr.key > /etc/ssl/private/idp.mondomaine.fr.key
  • Pour terminer, il faut remplacez les chaines de certificats. Vous devez adapter les chaînes de certificats selon votre prestataire.

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 :

  • Téléchargez le programme Java suivant :

  • Compilez le programme :

    javac InstallCert hostname

     Attention Pour mondomaine.fr hostname=cas.mondomaine.fr

  • On vous demande d'ajouter les certificats. Ajoutez les tous.

    Enter certificate to add to trusted keystore or 'q' to quit: [1]

     Attention 1 pour certificat numéro 1, recommancez autant de fois que vous avez des certificats, cf. le paragraphe 3).

  • Copiez le KeyStore Java "jssecacerts" crée dans le répertoire courant ici :

    cp jssecacerts $JAVA_HOME/jre/lib/security
  • Vérifiez les droits ou fixez les :

    chown root:root $JAVA_HOME/jre/lib/security/jssecacerts
    chmod 644 $JAVA_HOME/jre/lib/security/jssecacerts
  • Pour finir, relancer Tomcat :

    /etc/init.d/tomcat stop
    /etc/init.d/tomcat start

    Remarque : si vous souhaitez que ces certificats soient reconnus comme de "confiance" par toutes vos applications Java et pas seulement JSSE, écrasez "cacert" avec "jssecacerts".