Utilisation des modules (pour l'IdP Shibboleth 4.1 et supérieur)

A partir de la version 4.1 de l'IdP Shibboleth, une nouvelle architecture dédiée aux modules et aux plugins a été introduite dans l'IdP afin de gérer et faciliter tous les futurs ajouts de fonctionnalités et les extensions :

  • Modules
    • Activation/Désactivation indépendantes de chaque module avec bin/module.sh
    • Encapsulation des ensembles de fichiers de configuration pour minimiser l'empreinte des fonctionnalités inutilisées dans l’IdP
    • Mises à niveau permettant d'ajouter en toute sécurité des fichiers nouveaux et modifiés à l'aide des conventions .idpsave et .idpnew de type RPM
  • Plugins
    • Signés avec PGP et vérification de la signature obligatoire
    • Ajout de jar et d'autres fichiers à l’IdP
    • Gestion de l'installation/la mise à jour/la suppression avec bin/plugin.sh
    • Plugins et modules « travaillant en tandem »

L'activation d'un module permet d'ajouter automatiquement des fichiers optionnels de configuration, de vues… ; ces fichiers peuvent ensuite être adaptés en fonction des besoins.

Les modules et plugins sont décrits par le consortium Shibboleth à l'adresse suivante :

Il est préférable de désactiver les modules Hello World (idp.admin.Hello) et Demo (idp.authn.Demo) en production.

Dans cette fiche, nous présentons les commandes de base permettant d'activer, de désactiver et de configurer les modules.

Afichage de l'aide de la commande module.sh

La commande module.sh permet de gérer toutes les opérations concernant la gestion des modules

$>./bin/module.sh --help
ModuleManager
Provides a command line interface for IdP Module management operations.
 
   module [options] [springConfiguration]
      springConfiguration      name of optional Spring configuration resource to use
 
==== Command Line Options ====
  --help                 Prints this help information
  --version              Prints version
  --ansi                 Use ANSI color codes
  --lang                 Language range for i18n
  --propertyFiles        Comma-separated list of Spring property files
…
  -l, --list             Brief Information on all installed modules
  -i, --info <id>[,<id>] Full details on specific module(s)
  -t, --test <id>[,<id>] Test specific module(s) for enablement
  -e, --enable <id>[,<id>] Enable module(s)
  -u, --disable <id>[,<id>] Disable module(s)
  -f, --clean            Clean disabled files instead of preserving them

Listes des modules activés ou non

$>./bin/module.sh -l
Module: idp.authn.Duo			 [DISABLED]
Module: idp.authn.External 		 [DISABLED]
Module: idp.authn.Function 		 [DISABLED]
Module: idp.authn.IPAddress 		 [DISABLED]
Module: idp.authn.MFA 			 [DISABLED]
Module: idp.authn.Password 		 [ENABLED]
Module: idp.authn.RemoteUser 		 [DISABLED]
Module: idp.authn.RemoteUserInternal     [DISABLED]
Module: idp.authn.SPNEGO 		 [DISABLED]
Module: idp.authn.X509 		         [DISABLED]
Module: idp.authn.Demo 		         [DISABLED]
Module: idp.admin.Hello 		 [ENABLED]
Module: idp.admin.UnlockKeys 		 [DISABLED]
Module: idp.intercept.Consent 	         [DISABLED]
Module: idp.intercept.ContextCheck 	 [DISABLED]
Module: idp.intercept.ExpiringPassword   [DISABLED]
Module: idp.intercept.Impersonate 	 [DISABLED]
Module: idp.intercept.Warning 	         [DISABLED]
Module: idp.profile.CAS 		 [DISABLED]

A titre d'exemple, le module Hello World (idp.admin.Hello) permet de tester le comportement de base de l'IdP, comme l'authentification et la résolution d'attributs ; le module Warning Interceptor (idp.intercept.Warning) permet de gérer des conditions d’interruption et d’affichage de “vues d’avertissement” (“mot de passe expiré” par exemple).

Activation du module Intercept

$>./bin/module.sh -t idp.intercept.Consent || bin/module.sh -e idp.intercept.Consent
Enabling idp.intercept.Consent...
	conf/intercept/consent-intercept-config.xml.idpnew created
	views/intercept/attribute-release.vm created
	views/intercept/terms-of-use.vm created
[OK]

Les fichiers n'existant pas sont ajoutés directement alors que les ceux qui existent déjà (suite à une migration depuis un IdP 3 par exemple) sont renommés avec le suffixe .idpnew afin de ne pas perdre les customisations précédentes.

Information sur le module Intercept

$>./bin/module.sh -i idp.intercept.Consent
Module: idp.intercept.Consent
	Name: Consent Interceptors
	Desc: Interceptor flows for attribute and terms of use consent
	Help: https://wiki.shibboleth.net/confluence/display/IDP4/ConsentConfiguration
	Status: ENABLED
	Resource: (noreplace) conf/intercept/consent-intercept-config.xml
	Resource: (noreplace) views/intercept/attribute-release.vm
	Resource: (noreplace) views/intercept/terms-of-use.vm

Désactivation du module Intercept

$>./bin/module.sh -d idp.intercept.Consent
Disabling idp.intercept.Consent...
	conf/intercept/consent-intercept-config.xml renamed to conf/intercept/consent-intercept-config.xml.idpsave
	views/intercept/attribute-release.vm removed
	views/intercept/terms-of-use.vm removed
[OK]

Les fichiers qui n'ont pas été modifiés après leur installation sont supprimés directement alors que les ceux qui ont été modifiés sont renommés avec le suffixe .idpsave afin de ne pas perdre les customisations.

  • federation/documentation/fiches-techniques/idp/config-idp-modules.txt
  • Dernière modification : 2023/04/21 15:15
  • de ludovic.auxepaules@renater.fr