Comment remplacer Okta par Keycloak et GraphQL avec du low-code.
Opportunité
USH est une fédération de fédérations qui fournit des services de soutien central à ses membres. Elle fournit une infrastructure SSO et IAM pour plus de 20.000 utilisateurs. Okta était beaucoup trop cher et USH avait besoin de gérer de manière centralisée les comptes utilisateurs CRUD, de propager ensuite ces utilisateurs à de multiples autres applications : CRM, Active Directory, LDAP, site web Drupal, JIRA, activation des licences Microsoft Office et quelques autres applications internes.
Solution
Keycloak est utilisé comme IAM, très facile à intégrer, nous avons construit une couche middleware en utilisant Apollo GraphQL qui fournit un point de terminaison graphique unique pour toutes les opérations liées aux utilisateurs et enfin une belle application WeWeb front-end a été créée pour fournir un portail unifié pour créer, mettre à jour ou désactiver les utilisateurs.
Keycloak + GraphQL + WeWeb
Gérer plus de 20 000 utilisateurs est toujours un défi, surtout lorsqu'ils font partie de centaines d'organisations différentes et que leurs données sont réparties dans de multiples applications. En règle générale, ces problèmes sont résolus par une combinaison de solutions AD et IAM comme Okta. Cependant, la tarification d'Okta est orientée vers les entreprises, et avoir 20 000 utilisateurs implique généralement une très grande entreprise avec un budget substantiel.
USH, en revanche, est une fédération à but non lucratif qui fournit des services centralisés à ses membres, pour lesquels le coût d'Okta serait prohibitif. Nous avons conçu une solution plus élégante. La gestion des utilisateurs était basée sur Keycloak, un IAM open-source. Nous avons ajouté une couche GraphQL au-dessus de Keycloak pour gérer les utilisateurs et leurs données. Les résolveurs de GraphQL se connectaient à plusieurs API dorsales où se trouvaient des parties des données des utilisateurs : CRM, Drupal, LDAP, et d'autres où des actions étaient nécessaires lors de la création ou de l'archivage d'un utilisateur, comme l'octroi d'un accès JIRA, l'activation des licences Microsoft Office et la gestion des abonnements à la lettre d'information.
Enfin, nous avons créé un site front-end en utilisant WeWeb. Nous avons profité de la facilité de connexion de GraphQL à WeWeb et avons développé un ensemble d'écrans pour créer, mettre à jour, changer les emails et les attributs des utilisateurs existants, et archiver ceux qui sont partis, en les désactivant dans chaque application.
Pas aussi facile qu'il n'y paraît
Sur le papier, cela peut sembler simple : écrire quelques résolveurs avec Apollo GraphQL, connecter quelques API, créer trois ou quatre écrans sur WeWeb, et voilà. Mais en réalité, il s'agit d'un système hautement distribué qui implique l'orchestration et la synchronisation de données entre dix applications différentes. Un changement mineur ou une erreur peut déstabiliser l'ensemble du système. Le débogage était un véritable cauchemar ; nous pouvions passer plusieurs heures à enquêter sur une petite modification d'un attribut de champ qui interrompait tout le processus de création d'un utilisateur. Nous avions besoin d'urgence d'une solution pour éviter de passer trop de temps sur le projet.
Pour y remédier, nous avons d'abord mis en place un système de journalisation global à l'aide de Datadog. Nous avons également couvert la plupart des parcours utilisateurs avec des tests automatisés de bout en bout. Ces mesures ont immédiatement accéléré le projet, et nous sommes désormais en mesure d'exécuter et de déployer des changements en quelques minutes.
En outre, nous souhaitons souligner l'importance d'une communication inter-équipes efficace entre le département informatique d'USH, les intégrateurs Keycloak et les gestionnaires des différentes applications. Un JIRA, un Slack et un GIT uniques ont été mis en place, et des réunions régulières sur site ont été organisées pour aligner tout le monde et préparer les futures versions.