Migration

Introduction

Que vous passiez d'un fournisseur d'identité sur site à un IDaaS basé sur le cloud, ou d'un fournisseur de cloud à un autre, il n'y a pas de solution miracle pour rendre la transition transparente automatiquement. Vous n'êtes pas seul cependant, la plupart des entreprises finissent par passer par une migration du fournisseur d'identité une fois tous les 3 à 5 ans. Que ce soit pour des raisons monétaires ou pour offrir une meilleure expérience utilisateur, un plan de projet et des changements architecturaux sont inévitables. Cependant, il existe des modèles éprouvés qui vous aideront à rendre cette transition plus transparente et plus rentable, vous faisant gagner du temps et vous évitant des nuits blanches.

Les normes SAML et OpenID s'appuient sur des variables similaires pour établir une connexion de confiance avec le fournisseur d'identité, et grâce à ces variables, la sécurité est intégrée. Cependant, dans la majorité des cas, des changements sont absolument nécessaires au niveau du point de terminaison lors du passage d'un fournisseur d'identité à un autre. Cela signifie soit changer l'ID d'entité et les URL et certificats du consommateur d'assertion pour SAML, soit l'ID/secret client et les points de terminaison pour CI sur l'application pour les applications OpenID. La bonne nouvelle est que parce que SAML et OpenID sont basés sur des normes, rien n'a besoin d'être fait à vos applications autres que quelques étapes. Utilisez le concept d'"approche par phases" pour guider la planification de votre projet

Méthodologie par phases

Planification

Identifiez le modèle d'architecture pour avant, pendant et après la migration. Dans ce plan de migration, l'approche recommandée est de :

1. Faire du nouveau fournisseur d'identité (IdP) un "fournisseur de services" pour votre fournisseur d'identité actuel. Cela permet au nouveau IdP d'agir comme un proxy SAML et de simplement faciliter le déplacement en gardant les revendications d'attributs en place sans exiger que l'application apporte des modifications. L'autre avantage ici est qu'aucune nouvelle interface utilisateur n'est introduite. L'utilisateur final voit simplement une redirection dans son navigateur et personne n'y voit que du feu. L'expérience utilisateur actuelle reste intacte.
2. Déplacer les applications de l'ancien IdP vers le nouveau IdP. Échangez les ID clients, secrets, métadonnées SAML et tout autre point de terminaison d'API requis pour que l'application migre.
3. Supprimez votre ancien IdP en tant que fournisseur pour le nouveau service et pointez-le vers votre source d'enregistrement.
4. Décommissionnez votre ancien système et vous avez terminé !

Ayez des environnements de "test" prêts pour chaque application cloud et sur site critique si possible. La plupart des clients n'ont qu'un seul locataire Office365 ou GSuite (par exemple). Cela signifie que vous ne pourrez pas tester le nouveau système sur ces applications jusqu'à ce qu'il soit en production. Ce n'est pas une pratique recommandée. Bien que ces services coûtent de l'argent, il n'est pas sage de ne pas avoir une seule instance d'un service cloud.

Considérez "comment" vous communiquerez ces changements aux utilisateurs finaux. Si vous améliorez l'expérience de l'utilisateur final, alors vous devez communiquer pourquoi cela améliorera leur expérience. Il y a une raison à la migration après tout. Il est important d'être transparent avec les utilisateurs finaux, surtout parce que c'est ainsi que les utilisateurs s'authentifient à leurs applications chaque jour.

Choisissez des dates et des échéances spécifiques. Ironiquement, c'est une étape qui échoue dans de nombreux plans de projet : établir des échéances.

Déplacer les applications

Choisissez quelles applications migreront en premier, et lesquelles bougent en dernier. Il y a deux approches à cela, mais selon le type d'organisation que vous êtes ou le type de résultat que vous recherchez, l'une peut mieux fonctionner pour vous.

1. Applications les plus utilisées en premier / Applications peu utilisées en dernier
2. Applications peu utilisées en premier / Applications les plus utilisées en dernier

Il y a des avantages à prendre les "applications les plus utilisées" en premier : cela génère un gros impact, met moins de pression sur le plan de projet. Cependant, ce sont généralement des applications critiques pour l'entreprise.

Il y a aussi des avantages à prendre les "applications peu utilisées" en premier. Cela vous permet de ne pas avoir d'impact sur les applications majeures et critiques tout en vous assurant que les connaissances sont développées sur le nouvel outil par votre service d'assistance et vos administrateurs IT.

La meilleure approche est probablement une combinaison des deux. Mouillez-vous les pieds en déplaçant quelques applications plus petites et moins utilisées pour comprendre le nouvel outil et simultanément développer les connaissances et la sensibilisation, puis pour accélérer les choses une fois à l'aise, déplacez les applications plus importantes. Puis nettoyez les migrations avec les applications moins utilisées restantes à la fin.

Basculement

Toutes les applications doivent être déplacées à ce stade pour que cette étape se produise, sinon vous ferez fonctionner deux systèmes indépendants. Au fait, ce n'est pas nécessairement une mauvaise chose, mais c'est évidemment quelque chose à considérer avant d'effectuer le basculement.

Dans cette phase, vous introduirez probablement un nouveau thème ou une nouvelle interface utilisateur à vos utilisateurs finaux. C'est correct. De nos jours, notre culture a évolué pour devenir plus tolérante aux interfaces utilisateur changeantes (à l'exception de modifications majeures de l'expérience utilisateur). Fournir un aspect et une sensation similaires est important pour rendre cette migration plus directe, alors gardez cela à l'esprit lors de l'image de marque et de la thématisation de votre nouvelle expérience de connexion.

L'action requise dans cette phase est d'ajouter votre source d'enregistrement (répertoire) au nouveau fournisseur d'identité et de supprimer l'ancien service du mélange. Une fois que vous faites cette étape, le nouveau fournisseur d'identité prend le relais. L'authentification ne circulera plus vers l'ancien service.

Suppression des anciens composants

Après que toutes les applications soient déplacées, et que le basculement vers le nouveau fournisseur d'identité soit fait, vous avez maintenant la capacité de décommissionner votre ancien service.

La chronologie pour soutenir ce plan dépend de l'accès que vous avez avec vos fournisseurs, du nombre d'applications, et de la coopération des unités commerciales. Cependant, généralement parlant, ces migrations ne devraient généralement pas durer plus de 3 mois. Certaines organisations ont plus de contrôles de changement que d'autres, alors utilisez ceci comme un aperçu général.

💎

Adam Case, IBM Security