Documentation de référence : https://wiki.shibboleth.net/confluence/display/IDP30/Home

Téléchargez la dernière version 3 de l'IdP Shibboleth depuis http://shibboleth.net/downloads/identity-provider/ :

$> cd
$> wget http://shibboleth.net/downloads/identity-provider/latest3/shibboleth-identity-provider-3.4.7.tar.gz
$> wget http://shibboleth.net/downloads/identity-provider/latest3/shibboleth-identity-provider-3.4.7.tar.gz.asc
$> wget http://shibboleth.net/downloads/PGP_KEYS
$> gpg --import PGP_KEYS
$> gpg --verify shibboleth-identity-provider-3.4.7.tar.gz.asc
gpg: Signature faite le mer. 01 mai 2019 01:14:39 UTC avec la clef RSA d'identifiant 07CEEB8B
gpg: Bonne signature de « Tom Zeller <tzeller@dragonacea.biz> »
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg:             Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : 796D 70C8 9BBF 8D95 8925  F2ED 277E C86A 07CE EB8B
$> tar -zxf shibboleth-identity-provider-3.4.7.tar.gz

Nous passons à présent à l'installation de l'IdP proprement dite. L'installation de l'IdP est interactive, vous devez répondre à plusieurs questions :

$> cd shibboleth-identity-provider-3.4.7/
$> sudo -E ./bin/install.sh
Source (Distribution) Directory (press <enter> to accept default): [/home/<login>/shibboleth-identity-provider-3.4.7]
**taper entrer**
Installation Directory: [/opt/shibboleth-idp]
**taper entrer**
Hostname: [mon-poste.fr]
**renseigner votre hostname: mon-poste.fr**
**taper entrer**
SAML EntityID: [https://mon-poste.fr/idp/shibboleth]
**taper entrer**
Attribute Scope: [renater.fr]
**renseigner votre domaine, ex: univ-test.fr**
**taper entrer**
Backchannel PKCS12 Password:
**renseigner un mdp**
**taper entrer**
Re-enter password:
**renseigner le mdp**
**taper entrer**
Cookie Encryption Key Password:
**renseigner un mdp**
**taper entrer**
Re-enter password:
**renseigner le mdp**
**taper entrer**

Warning: /opt/shibboleth-idp/bin does not exist.
Warning: /opt/shibboleth-idp/edit-webapp does not exist.
Warning: /opt/shibboleth-idp/dist does not exist.
Warning: /opt/shibboleth-idp/doc does not exist.
Warning: /opt/shibboleth-idp/system does not exist.
Generating Signing Key, CN = mon-poste.fr URI = https://mon-poste.fr/idp/shibboleth ...
...done
Creating Encryption Key, CN = mon-poste.fr URI = https://mon-poste.fr/idp/shibboleth ...
...done
Creating Backchannel keystore,  CN = mon-poste.fr URI = https://mon-poste.fr/idp/shibboleth ...
...done
Creating cookie encryption key files...
...done
Rebuilding /opt/shibboleth-idp/war/idp.war ...
...
BUILD SUCCESSFUL
Total time: 1 minute 16 seconds

Cette procédure a installé l'IdP dans le répertoire /opt/shibboleth-idp/. Nous faisons en sorte que l'utilisateur tomcat dispose des droits nécessaires sur ce répertoire et son contenu:

$> sudo chown -R tomcat:tomcat /opt/shibboleth-idp

Parcourons l'arborescence de l'IdP :

• bin/ :Contient des outils de ligne de commande, et les bibliothèques de Java nécessaires lors de l'installation. Pendant les mises à niveau des fichiers supplémentaires que vous ajoutez seront préservés, pour pouvoir stocker vos propres scripts de ligne de commande.
• conf/ : contient les fichiers de configuration de l'IdP. Pendant toute installation (ou mises à jour), les fichiers ne sont jamais remplacés. Les nouveaux fichiers requis par la version en cours d'installation IdP seront ajoutés si elles ne existent pas.
  • access-control.xml : Contrôle l'accès à des fonctions administratives comme la page de statut, outil de test, les services de rechargement, etc.
  • attribute-filter.xml : Politique de contrôle des attributs qu’il faut retourner suite à une requête.
  • attribute-resolver.xml : Comment sont attribuées les données produites à partir de LDAP, base de données, ou d'autres sources de données, et la façon dont elles sont codées dans SAML ou d'autres formats (le nom officiel utilisé).
  • audit.xml : configuration du log d'audit
  • cas-protocol.xml : Configurer les fonctionnalités du protocole CAS.
  • credentials.xml : Configurer les clés privés et des certificats. Il n’est pas utilisable après une mise à niveau de la V2, jusqu'à ce que le fichier relying-party.xml soit (manuellement) converti du format V2 au format V3.
  • errors.xml : Configuration de l'association évènements-erreurs SAML.
  • global.xml : Un endroit pour mettre les définitions personnalisées des beans, vide par défaut.
  • idp.properties :Fichier de propriétés Java utilisé pour modifier les paramètres communs ou importants, utilisé comme un pointeur vers des sources supplémentaires de propriété.
  • ldap.properties : Fichier de propriétés Java avec l'authentification LDAP et paramètre de recherche d'attributs.
  • logback.xml : Configuration de journalisation Logback.
  • metadata-providers.xml : Configurer les sources de métadonnées SAML (une copie du relying-party.xml après une mise à niveau de la V2).
  • relying-party.xml : Contrôle les profils disponibles pour chaque SP.
  • saml-nameid.properties : Fichier de propriétés Java avec les paramètres contrôlant la production et la consommation du SAML NameID.
  • saml-nameid.xml : Contrôle la génération de SAML NameIDs.
  • services.properties : Fichier de propriétés Java avec des pointeurs vers les collections de ressources qui configurent les services, les paramètres importants de contrôle de politique et les configurations de rechargement.
  • services.xml : Contrôle des ressources chargées de configurer les services importants, et permet de configurer des services avancées telles que la subversion.
  • session-manager.xml : Configure la gestion de session, qui n’est pas géré avec des propriétés.
• credentials/ : les clés, certificats qui ont été générés lors de l'installation de votre IdP. Ces éléments sont exclusivement utilisés pour sécuriser les échanges SAML ; ils ne sont pas vus par les utilisateurs et ne nécessitent pas de signature par une autorité de confiance.
• dist/ : Contient les versions d'origine par défaut du contenu de la conf, flows, messages.
• doc/ : Contient la documentation, les licences, et autres liens.
• edit-webapp/ : Ce répertoire est créé lors de l'installation initiale. Vous pouvez placer toutes les configurations que vous souhaitez inclure dans votre fichier war.
• flows/ : Contient les definitions des user-esditable Spring Web Flow.
• logs/ : Contient les journaux de diagnostic et d'audit de l'IdP par défaut.
• messages/ : Contient les propriétés des messages internationalisés utilisés dans divers modèles d'interface utilisateur.
• metadata/ : Un emplacement de stockage des métadonnées SAML utilisée par l'IdP (voir MetadataConfiguration). Lors de l'installation initiale, certaines métadonnées SAML sont générées en fonction des entrées d'installation et placé dans ce répertoire dans un fichier nommé idp-metadata.xml.Notez que l'IdP n'a pas besoin de charger ses propres métadonnées, un changement de la V2.
• system/ :Contient la configuration du système interne qui ne devrait pas être modifié.
• views/ : Contient les modèles Velocity affichés aux utilisateurs de l'IdP. les JSP views (et les taglibs de la V2) sont généralement pris en charge, la plupart des vues de WebFlow fournis par défaut sont maintenant des templates de Velocity qui peuvent être maintenues en dehors du fichier war et modifiés lors de l'exécution.
• war/ : contient l'archive de l'IdP, pas besoin de la déplacer pour le déploiement grâce au fichier tomcat/conf/Catalina/localhost/idp.xml créé auparavant. Tomcat déploiera l'archive idp.war à la volée si celui-ci est démarré.
• webapp/ : contient le contenu décompressé du fichier WAR. Le contenu de ce répertoire est systématiquement écrasé lors d'une installation ou d'une mise à jour. Ne pas modifier le contenu de ce répertoire.

Nous allons créer un fichier XML qui permettra à Tomcat de déployer automatiquement la brique IdP sans avoir à recopier l'archive « .war » dans le répertoire webapps/ de Tomcat. Cette méthode de déploiement permet aussi d'éviter des problèmes de mise en cache parfois mal gérées par Tomcat. Pour cela, nous allons créer un fichier de configuration dédié /opt/tomcat/conf/Catalina/localhost/idp.xml, qui doit être accessible en lecture à l'utilisateur tomcat:

$> sudo mkdir -p /opt/tomcat/conf/Catalina/localhost/

/opt/tomcat/conf/Catalina/localhost/idp.xml

<Context docBase="/opt/shibboleth-idp/war/idp.war"
         privileged="true"
         antiResourceLocking="false"
         swallowOutput="true" />

Pour démarrer l'IdP Shibboleth, démarrer (ou redémarrez) votre serveur Tomcat :

$> sudo systemctl restart tomcat

Le compte-rendu d'installation mentionne la création d'un certain nombre de fichiers sensibles. Voici une liste de ces fichiers, dans le répertoire /opt/shibboleth-idp/credentials/ :

• idp-backchannel.crt : certificat pour les échanges SOAP (cas d'usage atypique),
• idp-backchannel.p12 : keystore PKCS12 contenant la clé privée pour les échanges SOAP, mentionné en tant que “TLS keystore” ci-dessus (cas d'usage atypique),
• idp-encryption.crt : certificat pour chiffrer des assertions SAML (utilisé uniquement pour le logout),
• idp-encryption.key : clé privée pour vérifier les assertions SAML chiffrées (utilisé uniquement pour le logout),
• idp-signing.crt : certificat pour signer des assertions SAML,
• idp-signing.key : clé privée pour vérifier la signature des assertions SAML,
• sealer.jks : keystore de type JCEKS (DataSealer) utilisé pour stocker la clé de chiffrement des cookies de session
• sealer.kver : fichier associé au keystore sealer.jks indiquant quelle clé est actuellement utilisée.

La procédure d'installation génère deux certificats (plus précisément: deux couples clés/certificats) distincts pour deux usages différents:

• signature des messages émis
• chiffrement par l'expéditeur des messages reçus

Il est parfaitement possible d'utiliser un certificat unique, mais différencier les usages simplifie le remplacement de ces certificats. Néanmoins, une limitation actuelle du guichet empêche de spécifier les usages associés: c'est le certificat de signature qu'il faut déclarer comme certificat courant.

Le rôle de ce fichier est présenté au chapitre sécurisation de l'IdP

Examinez les logs de Tomcat pour voir si son démarrage s'est bien déroulé et que le fichier idp.war a été déployé dans l'environnement Tomcat (le répertoire /opt/tomcat/work/Catalina/localhost doit correspondre au contenu de l'archive). Sinon vérifiez que le fichier de configuration /opt/tomcat/conf/server.xml comporte une directive autoDeploy comme dans l'exemple ci-dessous :

/opt/tomcat/conf/server.xml

<Host name="localhost" appBase="webapps" unpackWARs="true" **autoDeploy="true"** >

Redémarrez votre serveur Tomcat pour voir les logs de démarrage de l'IDP :

$> sudo systemctl restart tomcat
$> sudo tail -f /opt/shibboleth-idp/logs/idp-process.log
$> sudo tail -f /opt/tomcat/logs/catalina.out

Vous pouvez obtenir des informations sur l'état de votre serveur IdP de deux manières.

1) exécutez le script status.sh

$> /opt/shibboleth-idp/bin/status.sh
### Operating Environment Information
operating_system: Linux
operating_system_version: 3.10.0-957.10.1.el7.x86_64
operating_system_architecture: amd64
jdk_version: 1.8.0_262
available_cores: 2
used_memory: 321 MB
maximum_memory: 2000 MB

### Identity Provider Information
idp_version: 3.4.7
start_time: 2020-09-15T16:20:13+02:00
current_time: 2020-09-15T16:20:14+02:00
uptime: 1525 ms

service: shibboleth.LoggingService
last successful reload attempt: 2020-09-15T14:17:54Z
last reload attempt: 2020-09-15T14:17:54Z

service: shibboleth.ReloadableAccessControlService
last successful reload attempt: 2020-09-15T14:17:57Z
last reload attempt: 2020-09-15T14:17:57Z

service: shibboleth.MetadataResolverService
last successful reload attempt: 2020-09-15T14:17:56Z
last reload attempt: 2020-09-15T14:17:56Z

service: shibboleth.RelyingPartyResolverService
last successful reload attempt: 2020-09-15T14:17:56Z
last reload attempt: 2020-09-15T14:17:56Z

service: shibboleth.NameIdentifierGenerationService
last successful reload attempt: 2020-09-15T14:17:56Z
last reload attempt: 2020-09-15T14:17:56Z

service: shibboleth.AttributeResolverService
last successful reload attempt: 2020-09-15T14:17:56Z
last reload attempt: 2020-09-15T14:17:56Z

	DataConnector staticAttributes: has never failed

service: shibboleth.AttributeFilterService
last successful reload attempt: 2020-09-15T14:17:55Z
last reload attempt: 2020-09-15T14:17:55Z

2) accédez à l'URL https://mon-poste.fr/idp/status

$> /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.ReloadableAccessControlService