Intégration SSO Planzone 7

09.09.2022
─

ING Virsna
Augeo Software
18 rue Pasteur
94270 Le Kremlin-Bicêtre
 1

Vue d'ensemble
Document décrivant le système utilisateurs dans Planzone. Ce document est destiné aux
partenaires désirant intégrer leur propre gestionnaire utilisateur dans Planzone, et aussi
aux collaborateurs qui seront amenés à travailler sur tout sujet concernant les utilisateurs
dans Planzone.

Objectifs
1. Amener le lecteur à comprendre comment fonctionne le système utilisateur dans
Planzone.
2. Comprendre les différences dans la gestion des utilisateurs entre Planzone 6 et
Planzone 7
3. Montrer comment une intégration d’un gestionnaire utilisateur tiers est possible
dans Planzone 7

Caractéristiques
Ce document est divisé en quatre parties.
La première partie décrit l’architecture globale de Planzone dans la version 6 et la version
7. On y verra quelle pile logiciel y est utilisée et quelles sont les conséquences sur la
maintenance et sur les possibilités d’intégration .
La deuxième partie décrit le modèle de données de Planzone dans les deux versions. Le
modèle présenté est simplifié pour ne montrer que les éléments pertinents au système
utilisateur de Planzone. Nous verrons comment le modèle de Planzone permet les
intégrations SSO.
La troisième partie décrit le protocole de connexion de Planzone dans les deux versions.
Nous allons montrer dans cette partie comment se déroule le processus de connexion
dans Planzone, et comment il peut se dérouler dans un autre gestionnaire utilisateur.
La quatrième partie décrit le protocole d’inscription de Planzone dans les deux versions.
Nous allons expliquer dans cette partie comment Planzone ajoute un nouvel utilisateur
dans son système et comment un autre système peut ajouter des nouveaux utilisateurs
dans Planzone.
 2

Architecture

I. Planzone 6
Le Planzone 6 est servi par 2 services:

● Apereo CAS 5.2 Server, qui gère uniquement le premier niveau de connexion
à Planzone. la pile logicielle de CAS est la suivante:
○ MySQL 5.7
○ Java 1.8
○ Spring Boot 1.5
○ CAS 5.2
○ Tomcat 7
○ Maven 3

● Planzone 6 Application Server qui gère le deuxième niveau de connexion à

Planzone et toutes les autres fonctionnalités de Planzone, y compris
l’inscription des nouveaux utilisateurs. La pile logicielle du serveur
d’application est la suivante:
○ MySQL 5.7
○ Java 1.7
○ Hibernate
○ JSF 1.2
○ Tomcat 6
○ Maven 3
 3

Cette architecture est hérité de Planzone 5 où tout était géré par le serveur
applicatif. Les avantages et inconvénients de cette architecture sont:
Avantages:
● Déploiement facile, car peu de services à déployer.
● Infrastructure simple
● Un seul projet à maintenir

Inconvénients:
● Grande complexité générale
● Plus susceptible d’avoir des bugs
● Les bugs sont plus difficiles à corriger
● Fort couplage entre les fonctionnalités.
 4

Ce dernier point rend difficile la maintenance et l’ajout de nouvelles fonctionnalités, et

donc l’intégration d’outils tiers. Ainsi la modification d’un module entraîne potentiellement
la nécessité de vérifier et corriger les modules qui lui sont liés (cela peut aller jusqu’à toute
l’application).
 5

II. Planzone 7
Planzone 7 a une architecture microservice. Cela signifie que Planzone est servi par
des services plus nombreux mais plus petits avec une responsabilité plus limitée.
Ainsi Planzone 7 est composée de :
● D’un Front-end Web en ReactJS, qui sert d’interface entre Planzone et
l’utilisateur final
● De plusieurs API Restful. Chaque API est responsable d’une fonctionnalité de
Planzone
● Un serveur d’authentification CAS 6.6 qui gère la connexion et l’inscription de
l’utilisateur à Planzone.
L

Cette architecture est nouvelle dans Planzone, les avantages et les inconvénients de
cette architecture sont:
 6

Inconvénients:
● Le nombre de projets à maintenir augmente
● les services déployés doivent être à jour et synchronisées

Avantages:
● Faible couplage entre les fonctionnalités.
● Faible complexité générale
● Moins susceptibles d’être buggé
● Les bugs sont plus facile à corriger
● les différentes services sont agnostiques entre eux

Ce dernier point entraîne une conséquence très importante: chaque API peut utiliser
n’importe quel autre service à partir du moment qu’elle respecte une interface commune.
Par exemple, le Front-End Web fait appel à CAS, et à l’API User pour gérer ses utilisateurs.
Mais il peut très bien utiliser n’importe quel autre gestionnaire d’utilisateur à partir du
moment que ce gestionnaire ait la même interface que CAS et l’API User
Le faible couplage entre les fonctionnalités permet de pouvoir faire modification entraînant
des vérifications et des corrections limitées, ce qui facilite l’intégration d’outils tiers.
 7

Modèle de donnée

III. Planzone 6
Le modèle de donnée de Planzone 6 se présente sous la forme du schéma suivant :

Le système utilisateur de Planzone 6 repose sur les tables suivantes:

● La table User représente un utilisateur final de Planzone. c’est là où sont
stockées les informations concernant le profil utilisateur (nom, prénom
etc,...), et les informations de connexions (email, mot de passe, googleId,
SSO, …)
● la table Email représente l’adresse email de l’utilisateur
 8

● la table Planzone représente la Planzone de l’utilisateur (le produit)

● la table UserAccount représente l’utilisateur au sein d’une Planzone
● la table Resource représente une personne au sens projet, une Ressource est
soit:
○ humaine ( alors il y a une relation 1-1 avec la table UserAccount)
○ virtuelle ou matérielle ressource (alors il n y a pas de relation avec la
table UserAccount)
Ainsi les tables User et Email sont des tables destinées à la gestion des utilisateurs, alors
que les tables Planzone, et Resource sont des tables destinées au cœur produit
(c'est-à-dire la gestion de projet).
La table UserAccount sert de jointure entre les deux modules.
Il est à noter que toutes ces tables sont dans le même schéma à l’image de l’architecture
monolithique de Planzone 6. Ainsi les tables de gestion des utilisateurs et ceux du cœur du
produit sont fortement couplées ce qui entraîne le même genre d’inconvénients qu’avec
l’architecture logicielle.
 9

IV. Planzone 7
Le modèle de donnée de Planzone 7 se présente sous la forme du schéma suivant
pour l’API Core :

Nous avons les tables suivantes:

● la table Planzone représente la Planzone de l’utilisateur (le produit)
● la table UserContext (anciennement UserAccount) représente l’utilisateur au
sein d’une Planzone
● la table Resource représente une personne au sens projet, une Ressource est
soit:
○ humaine ( alors il y a une relation 1-1 avec la table UserAccount)
○ virtuelle ou matérielle ressource (alors il n y a pas de relation avec la
table UserAccount)

Pour l’API User nous avons le schéma suivant où seule la table User est pertinente.
 10

Ainsi les tables de gestion des utilisateurs sont indépendantes et découplées de celles du
cœur du produit. La UserContext (UserAccount) n’est plus une table de jointure entre un
utilisateur et une Planzone mais une simple référence vers un utilisateur qui peut très bien
se trouver dans une gestionnaire d’utilisateur complètement indépendant de Planzone.
 11

Protocole de connexion

V. Planzone 6

Voici comment se déroule une connexion sur Planzone 6 de manière générale:

 12

● l'utilisateur s'authentifie via le client CAS

● le serveur CAS autorise la connexion si les informations d'authentification sont
correctes
● le client CAS valide le TGT et soumet un ST à Planzone 6
● Planzone 6 valide le ST, et demande les informations utilisateurs au serveur CAS
● le serveur CAS envoie les informations utilisateurs à Planzone 6
● Planzone 6 génère un cookie de session
● si l'utilisateur n'est associé à aucune Planzone, alors Planzone 6 affiche une page
d'inscription
● si toutes les Planzones de l'utilisateur sont expirées, alors Planzone 6 affiche une
page de demande de renouvellement
● si au moins une de Planzones est active, alors Planzone 6 affiche la Planzone active
la plus récemment utilisée.

Le déroulement peut varier en fonction des méthodes de connexion

Email et mot de passe:

● l'utilisateur soumet son email et son mot de passe via le client CAS au serveur CAS
● le serveur CAS recherche l'utilisateur correspondant dans la base de donnée
● si l'utilisateur est trouvé, le serveur CAS vérifie la correspondance avec le mot de
passe
● si le mot de passe correspond, le serveur CAS autorise la connexion

Google:
● l'utilisateur clique sur le bouton "Connexion avec Google"
● l'utilisateur est redirigé vers la page de connexion de Google
● l'utilisateur valide sa connexion avec Google
● l'utilisateur est redirigé vers CAS qui autorise la connexion
● Planzone 6 tente de retrouver en base de donnée le compte avec le googleId
correspondant
● si le compte est trouvé, l'utilisateur peut utiliser les Planzones actives associés à ce
compte

SSO tiers ( si on devait faire une intégration SSO, cela se passerait comme suit):
● l'utilisateur utilise une page de connexion personnalisé (côté Planzone 6)
 13

● l'utilisateur clique sur le bouton "Connexion avec ..."

● l'utilisateur est redirigé vers la page de connexion côté SSO
● l'utilisateur valide sa connexion avec le SSO
● l'utilisateur est redirigé vers CAS qui autorise la connexion
● Planzone 6 tente de retrouver en base de donnée le compte avec l'id SSO
correspondant
● si le compte est trouvé, l'utilisateur peut utiliser les Planzones actives associées à ce
compte
.

VI. Planzone 7

Voici comment se déroule une connexion sur Planzone 7:

● l'utilisateur s'authentifie via le client CAS
● si les informations d'authentification sont correctes, le serveur CAS génère un token
d'Autorisation OAuth2
● l'utilisateur est redirigé vers une page de consentement
● l'utilisateur confirme les consentements demandées en cliquant sur "J'accepte"
● le serveur CAS génère un token JWT signé contenant:
○ le token d’Acces OAuth2
○ le token de Rafraîchissement OAuth2
○ les informations utilisateur
● le token JWT peut maintenant être utilisé pour accéder aux ressources protégées
des microservices
 14

Le déroulement peut varier en fonction des méthodes de connexion

Email et mot de passe:
● l'utilisateur soumet son email et son mot de passe via le client CAS au serveur CAS
● le serveur CAS transfère l'email et le mot de passe à l'API User
● l'API User vérifie la requête du serveur CAS et lui renvoie la réponse
● Si la réponse reçue est positive, CAS renvoie le token JWT signé

Google:
● l'utilisateur clique sur le bouton "Connexion avec Google"
● l'utilisateur est redirigé vers la page de connexion de Google
● l'utilisateur valide sa connexion avec Google
● l'utilisateur est redirigé vers CAS qui valide la connexion
● le serveur CAS récupère les attributs utilisateur de Google et de l'API User
● le serveur CAS génère le token JWT signé

SSO tiers ( si on devait faire une intégration SSO, cela se passerait comme suit):
● l'utilisateur valide sa connexion avec le SSO tiers
● l'utilisateur est redirigé vers CAS qui valide la connexion
● le serveur CAS récupère les attributs utilisateurs du SSO et de l'API User
● le serveur CAS génère le token JWT signé
 15

Provisionning

VII. Planzone 6

Email et mot de passe:

 16

● l'utilisateur se rend dans la page d'inscription de Planzone 6

● l'utilisateur rentre son email et son mot de passe
● Planzone 6 envoie un lien d'activation dans la boite email de l'utilisateur
● l'utilisateur clique sur le lien d'activation
● l'utilisateur est redirigé vers un formulaire d'inscription
● l'utilisateur remplit le formulaire d'inscription et le valide
● Planzone 6 créé si nécessaire une nouvelle Planzone
● l'utilisateur peut maintenant utiliser Planzone 6

Google:
● l'utilisateur crée un compte utilisateur avec la méthode email et mot de passe
● l'utilisateur se connecte sur Planzone 6 avec son email et son mot de passe
● l'utilisateur se rend dans les préférences
● l'utilisateur clique sur "Associer avec Google"
● l'utilisateur est redirigé vers la page de connexion de Google
● l'utilisateur valide sa connexion avec Google
● l'utilisateur revient dans Planzone 6 qui fait l'association
● l'utilisateur peut maintenant se connecter dans Planzone 6 avec Google

SSO tiers ( si on devait faire une intégration SSO, cela se passerait comme suit):
● l'utilisateur crée un compte utilisateur avec la méthode email et mot de passe
● l'utilisateur se connecte sur Planzone 6 avec son email et son mot de passe
● l'utilisateur se rend dans les préférences
● l'utilisateur clique sur "Associer avec SSO"
● l'utilisateur est redirigé vers la page de connexion du SSO
● l'utilisateur valide sa connexion avec le SSO
● l'utilisateur revient dans Planzone 6 qui fait l'association
● l'utilisateur peut maintenant se connecter dans Planzone 6 avec le SSO

VIII. Planzone 7
 17

Email et mot de passe:

● l'utilisateur clique sur le bouton "S'inscrire"
● l'utilisateur est redirigé vers la page d'inscription
● l'utilisateur valide via le formulaire d'inscription ses informations utilisateur
● le serveur CAS envoie un lien de validation
● l'utilisateur clique le lien de validation et est redirigé vers une page de saisie de mot
de passe
● l'utilisateur valide son mot de passe
● le serveur CAS crée la Planzone,
● la ressource associé à l'utilisateur est créé
 18

● et l'utilisateur peut commencer à utiliser Planzone

Google:
● l'utilisateur clique sur le bouton "Connexion/Inscription avec Google"
● l'utilisateur est redirigé vers la page de connexion de Google
● l'utilisateur valide sa connexion avec Google
● l'utilisateur est redirigé vers le serveur CAS
● le serveur CAS valide la connexion et l'utilisateur est redirigé vers Planzone 7
● Planzone 7 vérifie si un compte utilisateur existe ou pas
● si le compte existe, l'utilisateur utilise Planzone 7 avec ce compte
● sinon Planzone 7 crée un nouveau compte utilisateur
● Planzone 7 vérifie si une ressource Planzone est associé à ce compte utilisateur
● si c'est le cas, l'utilisateur utilise la Planzone associé à cette ressource
● sinon l'utilisateur doit créer une nouvelle Planzone, ou rejoindre une Planzone
existante
● c'est à dire, créer une nouvelle ressource associée au compte utilisateur.

SSO tiers, self sign-in ( si on devait faire une intégration SSO, cela se passerait comme suit):
● l'utilisateur s'inscrit ou se connecte via son SSO
● le SSO doit générer un token JWT signé:
○ Soit CAS Planzone 7 signe le token JWT
○ Soit Planzone 7 doit reconnaître la signature du token du SSO
● Planzone 7 vérifie la signature et décode le token JWT pour extraire les informations
utilisateurs
● Planzone 7 vérifie les informations utilisateurs
● Planzone 7 vérifie si une ressource Planzone est associé au compte utilisateur du
SSO
● si c'est le cas, l'utilisateur utilise la Planzone associé à cette ressource
● sinon l'utilisateur doit créer une nouvelle Planzone, ou rejoindre une Planzone
existante
● c'est-à-dire, créer une nouvelle ressource associée au compte utilisateur.

SSO tiers, création d'utilisateurs par lot ( si on devait faire une intégration SSO, cela se
passerait comme suit):
● prérequis: être administrateur d'une Planzone
● l'administrateur de la Planzone obtient un token JWT pour utiliser les ressources de
l'API Core
 19

● l'administrateur crée dans la Planzone ses ressources

● l'administrateur associe les ressources créées aux comptes SSO
● c'est-à-dire créer des userContext
● les utilisateurs SSO peuvent maintenant utiliser Planzone 7