FCA – Guide de mise à niveau Shibboleth v4

Quelle que soit la plateforme d’exploitation que vous utilisez, il est impératif, pour des raisons de sécurité, que le logiciel vous servant de fournisseur d’identités (IdP) soit aussi récent que possible. Les IdP Shibboleth antérieurs à la version 4.0.1 arriveront au terme de leur vie utile en décembre 2020 et ce guide vous aidera à examiner les différentes façons de procéder à une mise à niveau.

Planifier une mise à niveau est l’occasion idéale d’explorer les nouvelles fonctionnalités du fournisseur d’identités et de déterminer si elles vous aideront à faire progresser votre feuille de route technologique. Sur le plan de la sécurité, l’IdP est un véritable pivot dans l’architecture des identités et des mesures de protection, car il touche ce qui suit :

  • l’authentification;
  • les autorisations;
  • la diffusion des attributs;
  • une activation homogène des services avec sceau de confiance multilatéral des fédérations.

La version 4.0.1 de Shibboleth offre la même stabilité et la même performance, mais avec de nouvelles fonctionnalités comme la procuration SAML et le soutien des identifiants OpenID Connect (OIDC) en tant que fournisseur OIDC (OP), tout en continuant de supporter l’intégration des flux multifactoriels à vos services.

REMARQUE : Pour des conseils plus détaillés, consultez le wiki sur Shibboleth.net. Nous vous exhortons à lire la documentation du site sur l’installation du logiciel afin de vous familiariser avec les dispositions générales. Prenez surtout connaissance des notes de mise à jour en les lisant attentivement pour relever les changements importants que vous pourriez devoir effectuer avant la mise à niveau.

En règle générale, aucun changement ne devrait être nécessaire avant une mise à niveau, mais des questions de sécurité ou des bogues importants peuvent exiger des mesures particulières à l’occasion.

Par où commencer?

Votre point de départ et la distance que vous voulez parcourir sur votre feuille de route technologique détermineront les mesures à adopter lors de la mise à niveau. Avoir un objectif précis vous aidera à dresser un plan et à suivre la bonne voie. Voici quelques points et questions qui devraient vous aider à partir de bon pied.

Principales recommandations du consortium Shibboleth

Le modèle adopté par le consortium est celui de la mise à niveau du logiciel « en place ». Nous vous recommandons vivement de lire le guide de la mise à niveau Shibboleth et de déployer une plateforme IdP d’essai pour maîtriser et valider chaque étape avant de sauter à la plateforme de production.

Trois facteurs doivent absolument être pris en compte.

  1. Si la mise à niveau s’applique à une version antérieure à la v4, vous devrez d’abord mettre la plus récente version v3 à jour et supprimer tous les avertissements d’obsolescence.
  2. Assurez-vous que les versions de Java et du conteneur servlet répondent aux contraintes du système pour la version v4. Si ce n’est pas le cas, mettez-les à niveau avant d’en faire autant avec l’IdP.
  3. L’usage de Java 11 est désormais obligatoire. Jetty 8 suffisait pour la v3 de l’IdP, mais la v4 exige Jetty 9.4+.

Comment procéder à la mise à niveau?

Les sites qui utilisent actuellement la v3.4.7 de Shibboleth devraient procéder à la mise à niveau sans oublier les considérations qui précèdent. Il se pourrait que de nombreuses étapes mentionnées plus bas soient déjà en cours d’exécution.Les sites utilisant une version antérieure (à la v3.4.7) pourraient éprouver des difficultés supplémentaires, la principale étant que les versions plus ancienne de l’IdP Shibboleth ne peuvent régler aisément les cas d’obsolescence ce qui soulèvera plusieurs obstacles lors de la mise à niveau.

Si vous utilisez une vieille version du logiciel, nous vous recommandons ce qui suit.

  • Aménagez un nouveau système (sur une plateforme d’exploitation actuelle ou une autre, plus robuste) pour les essais et la production.
  • Choisissez une installation technique qui convient à la v4 de l’IdP.
  • Appliquez les paramètres du site à l’IdP d’essai pour déterminer quels changements vous devrez apporter à la plateforme de production.
  • Commencez par effectuer un essai sur la plateforme d’essai fédérée de la FCA et ensuite seulement avec le nouvel hôte de production.

Installation de l’IDP

  • Suivez le guide d’installation pour déployer directement l’IdP sur une machine virtuelle. De cette manière, vous profiterez des fonctions de gestion du système d’exploitation (OS) et ferez en sorte que la version de Java installée soit la bonne, et émane d’une source fiable. La maintenir à jour vous demandera moins d’efforts.
  • Les sites qui aimeraient recourir à un modèle plus contemporain devraient envisager les conteneurs d’une plateforme d’accès à Internet2 fiable pour l’IdP.

Déterminez si vous préférez un modèle à conteneurs Docker pour exploiter l’IdP. Le dépôt du conteneur tiendra le logiciel Shibboleth v4 à jour et vous pourrez appliquer les paramètres de la FCA lors du déploiement du conteneur.

Maintenir la continuité des services pendant la mise à niveau

La mise à niveau prend souvent en charge le rôle et nom du service existant. Pour éviter des accrocs, prenez en compte ce qui suit.

  • Ne changez pas votre entityID sans quoi vous invaliderez les règles existantes que d’autres pourraient avoir définies.
  • Copiez la clé de signature SAML de votre plateforme de production sur la nouvelle instance afin de préserver les signatures et les méthodes de chiffrement et de décryptage en place.
  • Ne modifiez pas les points terminaux du protocole SAML, car les utilisateurs et les services essuieront un échec.
  • Préservez les secrets aléatoires spéciaux utilisés pour établir un identifiant unique, sinon vous invaliderez les liens entre l’utilisateur et les services auxquels il tente d’accéder. Par « secret aléatoire » (salt), on entend les données aléatoires ajoutées par une fonction à sens unique qui hache les données afin de prévenir les attaques par hachage automatiques (ici, la création d’un identifiant unique par le fournisseur d’identités).

Stratégies pour une mise à niveau homogène

Si vous suivez les recommandations qui précèdent, vous pourrez procéder aux essais sur la plateforme de pré-production à jour en annulant votre fichier d’hôte local et celui des testeurs. Ainsi, vous testerez le nouveau chemin en parallèle sur la plateforme de production et celle de pré-production, ce qui vous offrira une position de repli si jamais survient une difficulté. La mise à niveau s’effectuera aussi de façon transparente pour la FCA, vos utilisateurs et les fournisseurs de services avec qui vous faites affaires.

Adopter les nouvelles fonctionnalités du nouveau Shibboleth

Les organisations pourront saisir l’occasion d’avancer leur feuille de route technologique en profitant des nouvelles fonctionnalités et capacités de la plus récente version de l’IdP Shibboleth. Parmi celles les plus prisées, on retrouve le soutien des identifiants OIDC et la capacité de recourir à l’authentification Azure AD, grâce à la procuration SAML, désormais offerte par l’IdP Shibboleth.

Soutien du fournisseur d’identités Open ID Connect (OIDC)

Parce qu’il accepte les identifiants OIDC, l’IdP Shibboleth devient en soi un fournisseur d’identités OIDC (OP). Vous trouverez plus de précisions ici. Vous devrez avoir terminé l’installation de la v4.0.1 avant d’activer cette fonctionnalité pour vous en servir. La façon de procéder déborde d’un document sur une mise à niveau comme celui-ci. Nous vous recommandons de lire le wiki de Shibboleth pour en savoir plus.

Procuration SAML

La procuration SAML figure dorénavant parmi les principales fonctionnalités de l’IdP Shibboleth. Utiliser celui-ci comme plateforme de procuration signifie qu’on l’autorise à exploiter et à réutiliser de façon fiable le protocole de connexion d’un autre fournisseur d’identités en reproduisant ses attributs et ses informations, mais aussi en y ajoutant ou modifiant des données au passage. Cette fonctionnalité est indispensable pour que l’IdP Shibboleth se connecte à Azure AD ou à un autre fournisseur d’identités, et qu’on profite de cette expérience. Pour en savoir plus sur cette approche, veuillez communiquer avec l’équipe technique de la FCA à tickets@canarie.ca et réserver une séance d’information.

Connexion à Azure AD avec ou sans authentification multifactorielle avec la v4 de l’IdP Shibboleth

L’authentification Azure AD s’intègre à Shibboleth grâce à la fonction de procuration SAML. Plusieurs configurations sont possibles et dépendent dans une large mesure de volume des données institutionnelles transmises par Azure AD et de la nature de la connexion souhaitée. Pour en apprendre davantage sur cette approche, veuillez prendre contact avec l’équipe technique de la FCA à tickets@canarie.ca et réserver une séance d’information.