Memoire Online - Etude et mise en place d'un service cloud d'iam basé sur keycloak

Étude et Mise en place d'un service cloud de gestion des identités et des accès basé sur keycloak

Président	Pr. Samba NDiaye	Professeur
Superviseur de mémoire	Pr Abdoulaye Ly	Ingénieur
Examinateur 1 :	Pr Bassirou Toure	Doctorant
Examinateur 2 :	Pr. NGor Seck	Ingénieur

AVANT-PROPOS

L'Institut Supérieur d'Informatique (ISI) est un groupe privé d'enseignement supérieur universitaire et professionnel avec une expérience de plus de dix ans. Il a été créé par des professionnels du secteur des technologies de l'information et de la communication. Les diplômes délivrés par cet institut sont la licence, le master et éventuellement le doctorat. Les enseignements y sont dispensés dans les filières telles que Ingénierie Logiciel, Ingénierie informatique, Ingénierie réseaux et télécom, Communication et Marketing.... Ils s'inspirent des normes recommandées par le CAMES (Conseil Africain et Malgache pour l'Enseignement Supérieur), de l'ANAQ-SUP,...

Pour l'obtention du master professionnel en Génie logiciel à l'ISI, il est demandé à chaque étudiant l'élaboration d'un mémoire de fin de cycle. C'est dans cette optique que nous avons rédigé ce document qui s'intitule : Étude et Mise en place d'un service cloud de gestion des identités et des accès (IAM pour Identity and Access Management) basé sur keycloak.

Le sujet est intitulé « Étude et Mise en place d'un service cloud de gestion des identités et des accès (IAM pour Identity and Access Management) basé sur keycloak ». La plateforme va nous permettre de faciliter le développement d'applications plus sûres et plus sécurisées et de profiter pleinement des avantages de l'outil keycloak.

Afin d'offrir des fonctionnalités aux utilisateurs, il doit mettre à leur disposition une interface d'utilisation permettant son exploitation. Cette interface sera accessible via un service PaaS hébergé chez AWS(Amazon Web Services) .

Ce document est le fruit de notre travail de recherche durant les six mois consacrés à ce projet. Des difficultés n'ont pas manqué. Elles concernent particulièrement la disponibilité de données fiables et actuelles.

A mes parents pour leur amour inestimable, leur confiance, leur soutien, leurs sacrifices et toutes les valeurs qu'ils ont su m'inculquer.

A mon très cher ami Amadou Oury Diallo pour son soutien et sa présence tout au long de mon parcours universitaire.

A mon maître de mémoire Monsieur Abdoulaye Ly, pour sa disponibilité, son soutien et sa patience tout au long de l'élaboration de ce mémoire.

Avant toute chose, Gloire à Allah, Créateur de toute chose, Celui qui rend le difficile facile, l'impossible possible et Qui, par Sa Grâce a permis la réalisation de ce travail.

Je tiens à remercier mon directeur de mémoire Monsieur Abdoulaye Ly, professeur à l'Institut Supérieur d'Informatique ISI de Dakar, de m'avoir accueillie dans son équipe et d'avoir accepté de diriger ce travail. Sa rigueur scientifique, sa disponibilité, sa patience et son écoute ont permis à ce travail d'aboutir dans les meilleures conditions.

Mes remerciements s'adressent également à l'ensemble du corps professoral de l'ISI, et à tous mes professeurs depuis la maternelle pour leur apport dans mon éducation.

Qu'ils puissent trouver dans ce travail le témoignage de ma sincère gratitude et de mon profond respect.

Je tiens à remercier les membres du jury d'avoir évalué ce travail. Mes remerciements les plus chaleureux vont à tous mes camarades à l'ISI pour leurs encouragements et pour l'ambiance agréable tout au long de ces rencontres de travail.

La gestion des identités et des accès (IAM pour Identity and Access Management) est un moyen de gérer un ensemble donné d'identités numériques des utilisateurs, et les privilèges associés à chaque identité. Il s'agit d'un terme général qui couvre un certain nombre de produits différents qui remplissent tous la même fonction de base. Keycloak est un des nombreux outils de gestion des identités et des accès qui offre un certain nombre de fonctionnalités tel que l'authentification unique (SSO pour Single Sign On/Out) pour la gestion des identités et des accès. L'utilisation d'un outil tel que Keycloak est une première étape vers le développement de logiciels et applications plus sûrs et plus sécurisés. Cependant pour tirer de réels avantages dans l'utilisation d'un tel outil il faut une compréhension plus ou moins poussée de celui-ci, ce qui peut prendre un certain temps.

Ce mémoire propose un service cloud de gestion des identités et des accès basé sur keycloak. Il met à disposition des développeurs un service mesurable auquel ils peuvent souscrire et qui leur permettra de tirer pleinement parti des avantages et des facilités qu'offre l'outil keycloak pour le développement d'applications et logiciels sécurisés. Après une étude poussée et l'utilisation de keycloak, Nous avons choisi un ensemble d'outils permettant le développement de notre plateforme. Nous avons choisi un environnement de développement windows dans lequel on utilise docker pour l'installation de keycloak, visual studio a été choisi comme éditeur de code avec le langage node.js et une base de données local mysql. La plateforme sera déployée sur un cloud PaaS (Platform as a Service) chez Amazon Web Services AWS.

Identity and Access Management (IAM) is a means of managing a given set of digital user identities, and the privileges associated with each identity. It is an umbrella term that covers a number of different products that all perform the same basic function. Keycloak is one of a variety of identity and access management tools that offer a range of features such as Single Sign On/Out (SSO) for identity and access management. The use of a tool such as Keycloak is a first step towards the development of safer and more secure software and applications. However, to get real benefits from using such a tool requires a more or less advanced understanding of it, which can take some time.

This project proposes a cloud service for identity and access management based on keycloak. It provides developers with a measurable service that they can subscribe to and that will allow them to take full advantage of the benefits and amenities that the keycloak tool offers for the development of secure applications and software. After a close study and the use of keycloak, we have chosen a set of tools allowing the development of our platform. We chose a windows development environment in which we use docker for the installation of keycloak, visual studio was chosen as a code editor with the node.js language and a local mysql database. The platform will be deployed on a PaaS (Platform as a Service) cloud at Amazon Web Services.

Abréviation	Signification
IAM	Identity and Access Management
SP	Service Provider
IdP	Identity Provider
PaaS	Plateforme as a Service
SSO	Single Sign On/Out
MFA	Multi Factor Authentication
RBAC	Role Based Access Control
HIPAA	Health Insurance Portability and Accountability Act
AS	Authorization Server
RO	Resource Owner
RS	Resource Server
OTP	One Time Password
PAYG	Pay As You Go
OS	Operating System
HTTP	HyperText Transfer Protocol
JWT	Json Web Token
JWS	JWT Signé
API	Application Programing Language
SGBDR	Système de Gestion de Base de Données Relationnelle
UML	Unified Modeling Language
SQL	Structured Query Language
DC	Data Center
OIDC	OpenID Connect
SLA	Service-Level Agreement

Terme	Explication
OAuth	Protocole de sécurité très utilisé.
OIDC	Protocole de sécurité complémentaire de OAuth.
SAML	Protocole de Sécurité.
Pay As You Go	Système de Paiement utilisé par les provider cloud.
Provider	Fournisseur de services cloud.
Realm	Dans keycloak, espace de gestion des objets incluant les utilisateurs, les applications, les rôles et les groupes.
Service-Level Agreement	Accord entre un fournisseur de services cloud et un client qui assure le maintien d'un niveau de service minimum.
Data Center	Infrastructure composée d'un réseau d'ordinateurs et d'espaces de stockage.

1. 1. Chap1: Introduction Générale

«La sécurité n'est pas une fonctionnalité mais une nécessité». Jamais cette affirmation n'a autant été d'actualité qu'à cette époque où le système d'information des entreprises est de plus en plus complexe, ouvert et en constante évolution.

La sécurité de ce système, indispensable au bon fonctionnement de l'entreprise, repose sur une multitude de solutions, outils et technologies. Au coeur de ce système gravite le maillon à la fois le plus important et le plus vulnérable: l'utilisateur. Il ne peut y avoir de gestion optimale de la sécurité du Système d'Information SI sans maîtrise de l'identité et des droits d'accès de ce dernier: la mise en place d'une stratégie IAM et plus précisément d'une plateforme de gestion des identités et des accès permet à l'entreprise de fiabiliser la sécurité de son SI en protégeant son coeur névralgique.

Un autre point mais pas des moins importants est la constante évolution des entreprises qui se tournent de plus en plus vers les nouvelles technologies de cloud computing.

Gérer efficacement l'ensemble des identités de ses utilisateurs, tout en évoluant vers les nouvelles technologies imposées par cette époque d'innovation, est un vrai défi à l'heure où les systèmes d'informations se complexifient.

Cette complexité se ressent évidemment au niveau du développement des logiciels utilisés par les entreprises compliquant ainsi la tâche aux développeurs déjà assez surchargés par la livraison des fonctionnalités adaptées aux besoins des clients (entreprises et particuliers) et le respect des délais imposés par ces derniers tout en migrant vers les nouvelles technologies de cloud computing.

Ces dernières années, bon nombre d'outils ont été développés pour répondre à ce besoin, Keycloak est l'un de ces outils de gestion d'identité et des accès ayant fait ses preuves. Et pourtant si les entreprises ont pu bénéficier d'une sécurité plus stable et robuste elles restent cependant toujours dans les anciennes méthodes de développement, et les développeurs ne sont pas plus soulagés de leurs charges.

Tout ceci étant mis sur table, la solution idéale serait un outil qui, non seulement gère bien les identités et accès des utilisateurs mais qui soit également une solution qui répond aux exigences du cloud et fait gagner du temps aux développeurs. Ainsi nous nous proposons de mettre en place une solution cloud de gestion des identités et des accès, ceci, en prenant comme socle un outil d'IAM mature à savoir keycloak.

Étant moi-même développeuse, je suis apte à dire que bien souvent, nous développeurs, mettons nos compétences au service de bien de domaines ce qui n'est pas une mauvaise chose, au contraire, mais très rarement à notre service. Ce constat ajouté à la découverte des outils comme keycloak m'ont interpellé et ont suscité mon intérêt pour la mise en place d'un système qui non seulement sera bénéfique aux entreprises mais également à nous développeurs en nous allégeant la tâche et ainsi nous permettre de nous concentrer sur le développement des besoins fonctionnels et de livrer dans les délais impartis.

Afin de traiter le sujet et de répondre aux questionnements émis, un plan de recherche a été établi. Il consiste d'abord en une recherche documentaire qui s'est porté sur des livres électroniques et des conférences en ligne.Le tout s'est déroulé sur une période de deux mois. La recherche a été complétée par de nombreuses lectures sur le sujet.

Nous verrons dans un premier temps en détail le cadre dans lequel s'inscrit notre projet, le problème auquel il essaie d'apporter une solution, ses objectifs et les motivations qui ont poussé à la réalisation de ce projet. (chapitre I). Nous allons également analyser quelques solutions déjà existantes dans le domaine de la gestion des identités et des accès(chapitre II), avant de passer à la réalisation et l'implémentation de notre solution (chapitre III) et finalement conclure et énoncer les perspectives du projet(chapitre IV).

1.1. Contexte

Avec les avancées de l'internet, le développement des applications et de toutes sortes de solutions informatiques et en même temps du piratage de données ces dernières années, la nécessité d'avoir un système sécurisé n'est plus à prouver. Bien qu'étant un domaine à part, la sécurité est fondamentale dans tout processus de développement d'applications. Toutefois il peut être fastidieux de mettre en place un système d'authentification solide et fiable. On peut être bon développeur et développer des applications vulnérables, c'est pourquoi il est préférable de déléguer sa sécurité à un spécialiste.

Plusieurs techniques sont utilisées par les développeurs pour répondre à ce besoin: l'écriture des écrans de login, la gestion des utilisateurs et de leurs mots de passes, ou encore, l'utilisation de protocoles comme OAUTH 2.0. Une autre approche plus récente consiste à l'implémentation du SSO (Single Sign On / Single Sign Out). Les outils comme keycloak sont dédiés à cette dernière option.

Cependant, si l'utilisation d'un outil comme keycloak est très pratique, il faut noter que cela demande une certaine familiarité et la prise en main n'est pas des plus facile. Les configurations pouvant varier d'un projet à l'autre , il faut des connaissances poussées mais surtout de l'expérience et une courbe d'apprentissage assez importante pour parvenir à en tirer de réels bénéfices.

1.2. Problématique

Comment développer des applications sécurisées, fiables et performantes et en même temps gagner du temps dans le développement de ses applications? C'est une question que tout bon développeur doit se poser. Ce projet permettra d'apporter une solution à ce problème en mettant à disposition des développeurs un service cloud qui s'occupera de la gestion de la sécurité en se basant sur un outil de gestion des identités et des accès (IAM en anglais pour Identity and Access Management): «Keycloak», sans pour autant avoir besoin d'en être expert. Ce qui leur permettra de se consacrer au développement des fonctionnalités de leurs applications et ne plus se soucier de la mesquinerie liée à la sécurité.

1.3. Objectifs

1.3.1. Objectif Global

Suite à la question émise dans la problématique, nous aurons pour objectif final de ce mémoire, la mise en place d'un service cloud de gestion des identités et des accès basée sur l'outil Keycloak afin d'alléger la charge des développeurs et leur permettre de se concentrer sur les besoins fonctionnels des logiciels qu'ils développent.

Le service sera accessible via le cloud et permettra au développeur qui bénéficiera du service de gérer l'accès à son application de deux manières:

a. La première option: fait en sorte que lorsqu'un utilisateur d'une application utilisant notre service, essaie d'accéder à une ressource sécurisée, il est redirigé sur notre plateforme cloud et celle-ci se charge de son authentification, et en fonction du résultat obtenu l'application autorise ou non l'utilisateur en question à accéder à la ressource demandée.

b. La deuxième option: consiste à laisser à l'application(bénéficiant de notre service) le soin de gérer son interface et derrière il va faire appel au service cloud via une API pour authentifier ses utilisateurs.

1.3.2. Objectifs spécifiques:

Afin d'atteindre l'objectif principal, nous nous sommes fixés des objectifs spécifiques à atteindre durant les 6 mois accordés au projet. Ces objectifs sont les suivants:

1.4. Motivations

Ce projet de mémoire tire sa principale motivation d'un constat observé auprès des développeurs de tous les niveaux. Qu'ils soient débutants, juniors ou même seniors, tous les développeurs font face aux mêmes inquiétudes et aux mêmes tracas quand il s'agit de gérer la sécurité des applications qu'ils développent. Ceci est surtout dû au fait que la sécurité, bien qu'indispensable, est un domaine à part entière. Développer une application sécurisée est une tâche fastidieuse et chronophage, qui, bien souvent, aboutit à un résultat peu ou pas satisfaisant.

Avec cette plate-forme cloud, il sera possible pour le développeur de déléguer sa sécurité à un service tiers et spécialisé, ce qui lui fera gagner en temps, en productivité mais aussi en performance.

La réalisation de ce projet me permettra également, en tant qu'étudiante, d'approfondir mes compétences dans le domaine du développement logiciel mais également d'en acquérir de nouvelles dans le domaine de la sécurité tout ceci, en me familiarisant avec les nouvelles technologies de cloud computing.

Introduction

L'IAM pour Identity and Access Management (Gestion des Identités et des Accès en français) est une solution permettant de gérer de manière sûre et efficace les identités numériques des utilisateurs et les privilèges d'accès associés. Les administrateurs IAM peuvent définir et modifier les rôles des utilisateurs, suivre et rendre compte de l'activité des utilisateurs, mais aussi appliquer les politiques de conformité réglementaire et de l'entreprise pour protéger la sécurité et la confidentialité des données.

Une solution IAM définit ce à quoi les utilisateurs ont accès, ce qu'ils ont comme droit, rôle, et ce qui leur est refusé. L'objectif d'une stratégie efficace d'IAM est de répondre aux questions suivantes:

Une solution IAM gère le cycle de vie des utilisateurs, s'assure que les utilisateurs sont ceux qu'ils prétendent être et que tout ceci est facile d'accès. L'identité numérique est une source centrale de vérité dans la gestion des identités et des accès. Elle fait référence aux informations d'authentification dont un utilisateur a besoin pour accéder à des ressources en ligne ou sur un réseau pour grande entreprise. Les solutions IAM font correspondre ces informations d'authentification, appelées facteurs d'authentification, aux utilisateurs ou aux entités qui demandent l'accès aux applications, principalement au niveau de la couche applicative (couche 7). Ces facteurs permettent de vérifier que les utilisateurs sont bien ceux qu'ils prétendent être. Trois des facteurs d'authentification les plus couramment utilisés pour l'IAM sont quelque chose que l'utilisateur connaît (comme un mot de passe); quelque chose que l'utilisateur possède (comme une carte magnétique); et quelque chose que l'utilisateur est (une propriété physique, comme une empreinte du pouce). Un utilisateur doit généralement fournir une combinaison de facteurs d'authentification pour qu'une application d'authentification puisse confirmer son identité et lui accorder l'accès aux ressources protégées qu'il est autorisé à consulter ou à utiliser.

Un système IAM présente des avantages comme le renforcement de la sécurité car avec un système IAM, les entreprises peuvent appliquer les mêmes politiques de sécurité dans toute l'entreprise. Les méthodes d'IAM comme l'authentification unique (SSO) et la MFA réduisent également le risque que les informations d'authentification des utilisateurs soient compromises ou utilisées de manière abusive, car les utilisateurs n'ont pas besoin de créer et de conserver plusieurs mots de passe. Et parce que les utilisateurs ont besoin d'une autorisation fondée sur des preuves pour accéder à des ressources protégées, il y a moins de chances qu'un acteur malveillant obtienne l'accès à des ressources critiques.

Au sein d'un système IAM la conformité est également améliorée en aidant les organisations à répondre aux exigences de nombreux mandats de conformité liés à la sécurité et à la confidentialité des données. Par exemple, l'IAM peut contribuer à la conformité avec la loi HIPAA (Health Insurance Portability and Accountability Act), qui exige des organisations qui traitent des informations de santé protégées qu'elles mettent en oeuvre un accès électronique sécurisé aux données de santé.

Les entreprises peuvent utiliser des méthodes d'IAM telles que le SSO, le MFA, le contrôle d'accès basé sur les rôles (RBAC) et les « moindres privilèges » (donnant aux utilisateurs et aux entités telles que les applications logicielles le minimum d'accès requis pour effectuer une tâche) pour répondre au mandat de la loi HIPAA. L'IAM présente de nombreux autres avantages comme la réduction des coûts informatiques, la croissance de la productivité des utilisateurs ou employés dans le cas d'une entreprise.

Avec un IAM on peut donc autoriser ou bloquer l'accès aux ressources, restreindre l'accès à la plateforme, empêcher la transmission des données sensibles et fournir des rapports qui aident les organisations à prouver leur conformité avec les réglementations en matière de sécurité et de confidentialité des données.

Un JSON Web Token ou JWT est un access token (jeton d'accès) aux normes RFC 7519 qui permet un échange sécurisé de données entre deux parties. Il contient toutes les informations importantes sur une entité, ce qui rend donc la consultation d'une base de données superflue et la session n'a pas besoin d'être stockée sur le serveur (stateless session).

La génération d'un JWT peut se résumer en troisétapes assez élémentaires :

1) L'utilisateur se connecte depuis votre client qui va envoyer une requête HTTP au serveur (via l'API du serveur) avec, par exemple, un couple email/mot de passe

2) Si les informations de connexion sont correctes, le serveur génère un jeton JWT

3) Le serveur envoie le JWT généré au client, qui le conservera de son côté pour pouvoir le retourner au serveur à chaque nouvelle requête

Ainsi, dès que le serveur reçoit une requête, si celle-ci contient un JWT, le serveur vérifiera la validité du JWT et saura quel utilisateur est à l'origine de la requête.

Un JWT signé se compose de trois parties codées en base64 et séparées par un point:

? L'en-tête ou header: est en général composé de deux parties et fournit des informations essentielles sur le token. Il contient le type de token et l'algorithme de signature et/ou de chiffrement utilisé. Un exemple de header de JWT

? La charge utile ou payload: cette partie du JWT est la partie qui contient les informations qui doivent être transmises à l'application. C'est là que sont définis certains standards qui déterminent quelles données doivent être transmises. Les informations sont fournies en paire clé/valeur, les clés sont appelées «claims» dans les JWT. Il existe trois types de claims: les claims réservées, les claims publiques et les claims privées.

? La signature d'un JSON Web Token est créée grâce au codage base64 de l'en-tête et de la charge utile et la méthode de signature/cryptage spécifiée. La structure est définie par la JSON Web Signature (JWS), une norme standardisée selon le RFC 7515. Pour que la signature fonctionne, il est nécessaire d'utiliser une clé secrète connue uniquement de l'application source. Cette signature vérifie d'une part que le message ne sera pas modifié pendant le transfert. D'autre part, dans le cas d'un jeton signé avec une clé privée, il authentifie également l'expéditeur du JWT.

Un jeton d'accès OAuth ou access token en anglais est une chaîne que le client OAuth utilise pour faire des demandes au serveur de ressources.

Les jetons d'accès n'ont pas besoin d'être dans un format particulier, et en pratique, divers serveurs OAuth ont choisi de nombreux formats différents pour leurs jetons d'accès.

Un certain nombre de propriétés des jetons d'accès sont fondamentales pour le modèle de sécurité d'OAuth :

? Les jetons d'accès ne doivent pas être lus ou interprétés par le client OAuth. Le client OAuth n'est pas le public visé par le jeton.

? Les jetons d'accès ne transmettent pas l'identité de l'utilisateur ou toute autre information sur l'utilisateur au client OAuth.

? Les jetons d'accès ne doivent être utilisés que pour effectuer des requêtes auprès du serveur de ressources. De plus, les jetons d'identité ne doivent pas être utilisés pour effectuer des demandes au serveur de ressources.

Un refresh token ou jeton de rafraîchissement OAuth est une chaîne que le client OAuth peut utiliser pour obtenir un nouveau jeton d'accès sans l'interaction de l'utilisateur.

Un jeton de rafraîchissement ne doit pas permettre au client d'obtenir un accès au-delà de la portée de l'octroi initial. Le jeton de rafraîchissement existe pour permettre aux serveurs d'autorisation d'utiliser des durées de vie courtes pour les jetons d'accès sans avoir à impliquer l'utilisateur lorsque le jeton expire.

2.1.4. ID token

Un id token ou jeton d'identité est un jeton de sécurité qui contient des déclarations concernant l'authentification d'un utilisateur final par un serveur d'autorisation lors de l'utilisation d'un client, et éventuellement d'autres déclarations demandées. Le jeton d'identité est représenté sous la forme d'un JSON Web Token (JWT) avec signature cryptographique (JWS).

Les déclarations suivantes sont utilisées dans le jeton ID pour tous les flux OAuth 2.0 utilisés par OpenID Connect (on a cité là que les déclarations obligatoires et quelques unes qui peuvent l'être ou non selon le cas. Il en reste d'autres qui ne seront pas cités):

iss: Identifiant de l'émetteur pour l'émetteur de la réponse. La valeur iss est une URL sensible à la casse utilisant le schéma https qui contient des composants de schéma, d'hôte et, éventuellement, de numéro de port et de chemin d'accès et aucun composant de requête ou de fragment.
sub: Identifiant du sujet. Un identifiant localement unique et jamais réaffecté au sein de l'émetteur pour l'utilisateur final, qui est destiné à être consommé par le client, par exemple, 24400320 ou AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. Il ne doit pas dépasser 255 caractères ASCII. La sous-valeur est une chaîne sensible à la casse.
aud: Public(s) auquel ce jeton d'identité est destiné. Il doit contenir le client_id OAuth 2.0 de la partie utilisatrice comme valeur d'audience. Il peut également contenir des identifiants pour d'autres publics. Dans le cas général, la valeur aud est un tableau de chaînes sensibles à la casse. Dans le cas spécial courant où il n'y a qu'une audience, la valeur aud peut être une chaîne unique sensible à la casse.
exp
Heure d'expiration à partir de laquelle le jeton d'identité ne doit pas être accepté pour le traitement. Le traitement de ce paramètre nécessite que la date / heure actuelle doit être antérieure à la date / heure d'expiration répertoriée dans la valeur. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01 T 0:0:0 Z mesuré en UTC jusqu'à la date / heure.
iat: Heure à laquelle le JWT a été émis. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01 T 0:0:0 Z mesuré en UTC jusqu'à la date / heure.

auth_time: Heure à laquelle l'authentification de l'utilisateur final s'est produite. Sa valeur est un nombre JSON représentant le nombre de secondes à partir de 1970-01-01 T 0:0:0 Z mesuré en UTC jusqu'à la date / heure. Lorsqu'une demande max_age est effectuée ou lorsque auth_time est demandé en tant que revendication essentielle, cette revendication est obligatoire,sinon, son inclusion est facultative.
nonce: Valeur de chaîne utilisée pour associer une session client à un jeton d'identité et pour atténuer les attaques de relecture. La valeur est transmise sans modification de la demande d'authentification au jeton ID. S'il est présent dans le jeton d'identité, les clients doivent vérifier que la valeur de réclamation nonce est égale à la valeur du paramètre nonce envoyé dans la demande d'authentification. S'ils sont présents dans la demande d'authentification, les serveurs d'autorisation doivent inclure une réclamation nonce dans le jeton d'identité, la valeur de réclamation étant la valeur nonce envoyée dans la demande d'authentification. Les serveurs d'autorisation ne devraient effectuer aucun autre traitement sur les valeurs non utilisées. La valeur nonce est une chaîne sensible à la casse.

Voici un exemple non normatif de l'ensemble de revendications (l'ensemble de déclarations JWT) dans un jeton d'identification :

OAUTH 2.0 est un protocole qui sert à faire de la délégation de l'accès et de l'autorisation. Le but étant de savoir ce qu'on est autorisé à faire. Il fait intervenir quatre acteurs principaux à savoir: le client, l'Authorization Server AS, le Resource Owner RO et le Resource Server RS.

OAuth 2 propose différents types de flows. Le flow est le processus de délivrance de l'access token. Le type de flow à utiliser dépend le plus souvent du type de l'application, mais d'autres facteurs peuvent également entrer en jeu comme le niveau de confiance accordé au client.

Pour les applications web s'exécutant côté serveur, le flow utilisé est l'Authorization Code Flow. Par conséquent, c'est celui que nous allons traiter dans ce document.

Dans chaque flow, OAuth 2 garde la même terminologie. Autrement dit, les acteurs concernés par chacun des flows gardent la même terminologie. Ces acteurs sont:

? Le Resource Owner RO: c'est l'entité qui octroie les droits d'accès à une ressource protégée. Typiquement, l'utilisateur.

? Le Client: c'est l'application ou le service qui souhaite accéder à une ressource protégée au nom du RO.

? L'Authorization Server AS: c'est le serveur qui est chargé d'authentifier le RO. C'est aussi lui qui fournit les jetons d'accès Access Token.

? Le Resource Server RS: c'est le serveur qui détient la ressource protégée.

? User Agent UA: Agent utilisé par le RO pour interagir avec le client (par exemple, un navigateur ou une application native).

Ces informations sont demandées par le client au RO par l'intermédiaire du UA.

? Un access token qui permet d'accéder à la ressource avec une durée de vie limitée

Figure 2.5: Illustration du fonctionnement d'OAuth2 - Authorization code flow

2.1.6. OIDC pour OpenID Connect

Au niveau du protocole OAuth2., l'API ou le Resource Server RS qui fournit les informations au Resource Owner n'a aucun moyen de savoir si l'utilisateur est toujours connecté ou non. Ce qui pose problème parce qu'un client peut continuer à récupérer un access token à partir du refresh token alors que le Resource Owner RO est déconnecté, le RS n'a aucun moyen de le savoir. En cas d'authorization code injection, ou d'access token injection ou une autre attaque, l'attaquant peut accéder aux ressources du RO donc usurper l'identité du Resource Owner sur un service utilisant le protocole OAuth2. OpenID Connect est une couche qui vient s'ajouter à OAUTH 2.0 en mettant à disposition en plus de l'access token et du refresh token, un ID Token qui va porter l'identité de la personne connectée. OIDC a pour but d'identifier la personne derrière le navigateur ou l'application connecté à un service. La norme OIDC a été conçue spécifiquement pour l'authentification des utilisateurs.

2.1.7. SAML pour Security Assertion Markup Language

C'est un protocole ouvert et standardisé basé sur XML, il permet d'échanger des infos d'authentification et d'autorisation entre des entités ou domaines de sécurité. Il gère le processus d'échange entre :

Service Provider(SP) qui protège l'accès aux ressources demandées (site web, application, etc) en appliquant une politique de sécurité.

Identity Provider(IdP) qui répond à la demande du SP, il est chargé d'authentifier l'utilisateur et de forger les infos associées à l'identité et qui sont demandées par le SP.

2.1.8. SSO pour Single Sign On / Single Sign Out

Dans ce modèle l'utilisateur n'a besoin de s'authentifier qu'une fois (d'où le nom de SSO) et il est de facto authentifié auprès des autres fournisseurs de service. On utilise des credentials unique quelque soit le service demandé au sein du domaine d'identité. Ceci est aussi valable pour la déconnexion (Single Sign Out)

C'est un modèle de gestion de données dans lequel les SP(Service Provider) sont groupés pour former une fédération. Chacun des SP sera donc en mesure de reconnaître les identifiants provenant d'autres SP de la même fédération. La fédération donne aux utilisateurs l'illusion d'utiliser qu'un seul identifiant (mais derrière, il s'identifie auprès de chaque IdP). Chaque SP utilise son propre IdP mais reconnaît les identités provenant d'autres SP

2.2. L'outil Keycloak

Keycloak est un IAM (Identity and Access Management) open source, licencié par Apache et pris en charge par Red Hat. Il est écrit en Java et prend en charge les protocoles de fédération d'identité par défaut SAML V2, OIDC, OAUTH2.0. Le but de Keycloack d'un point de vue conceptuel c'est de faciliter la protection des applications et des services au moyen de configurations. Il fait du SSO, et il utilise la fédération d'identités pour se connecter à des serveurs comme Active Directory ou LDAP.Il est né du besoin commun des entreprises d'avoir un outil centralisé d'authentification et d'autorisation. Il apporte une gestion simplifiée via la console. Il gère l'authentification et l'identification.

Sous keycloak la notion d'authentication flow est évoquée. Selon la définition de keycloak: «Un flux d'authentification est un conteneur d'authentifications, d'écrans et d'actions, pendant la connexion, l'enregistrement et d'autres flux de travail de {nom_du_projet}.»

En d'autres termes, un flux d'authentification est un ensemble d'actions s'exécutant lors d'une connexion ou d'une inscription.

? La colonne "Requirement" définit si l'action est impérative, alternative, ou désactivée :

Keycloak offre plusieurs flux d'authentification et permet de passer facilement d'un flow à l'autre.

La mise en place d'une politique de mot passe est également offerte par l'outil keycloak et peut être gérée d'une manière simple et efficace. Il est possible de:

Un autre point important de keycloak est qu'il respecte les normes OWASP(The Open Web Application Security Project) pour l'implémentation des ses protocoles et permet ainsi à ses applications d'être en adéquation avec les normes de sécurité définies par OWASP.

2.3. Étude de l'existant

Les outils de gestion des identités et des accès (IAM), sont de plus en plus proposés sur le marché de la gestion de la sécurité des applications, renfermant tout un tas de fonctionnalités utiles pour la mise en place d'un système de sécurité performant. Ce chapitre présente les travaux réalisés par plusieurs entreprises apportant des solutions alternatives à notre problématique et fait ressortir la principale plus value qu'a notre projet par rapport à ses concurrents. Rappelons l'objectif fondamental de notre solution afin de définir les critères et les fonctionnalités de ces outils à analyser pour mener un état de l'art pertinent. Notre solution a pour principal objectif la réalisation d'une plateforme cloud de gestion des identité et des accès basée sur un outil d'IAM très connu «Keycloak», ceci afin de permettre aux développeurs d'optimiser la sécurité des leurs applications sans avoir à implémenter ou à configurer grand chose.

2.3.1. RH-SSO

RH-SSO pour Red Hat Single Sign On est une solution SSO développée par Red Hat, voici une présentation de l'outil tiré du site même de Red Hat:

«Red Hat Single Sign-On (RH-SSO) est basé sur le projet Keycloak et vous permet de sécuriser vos applications Web en fournissant des fonctionnalités d'authentification unique (SSO) basées sur des normes populaires telles que SAML 2.0, OpenID Connect et OAuth 2.0. Le serveur RH-SSO peut agir en tant que fournisseur d'identité basé sur SAML ou OpenID Connect, faisant office de médiateur avec votre annuaire d'utilisateurs d'entreprise ou un fournisseur SSO tiers pour les informations d'identité et vos applications via des jetons basés sur les normes.»

RH-SSO est une solution native. Vous pouvez l'installer en télécharger un fichier zip directement sur le site de Red Hat dans la partie dédiée à RH-SSO, en local vous avez la possibilité de l'utiliser en mode standalone, et il fonctionne dès le départ avec sa propre base de données intégrée (local uniquement). Pour les déploiement réels qui seront exécutés en production, vous devrez décider de la manière dont vous souhaitez gérer la configuration du serveur au moment de l'exécution (mode standalone ou domain), configurer la base de données partagée pour le stockage de RH-SSO pour qu'il fonctionne dans un cluster.

RH SSO permet entre autres de faire de l'authentification unique (Single-Sign On), de la fédération des utilisateurs, du courtage d'identité et connexion sociale et il met à disposition une API Rest pour la spécification des utilisateurs, leurs rôles et groupes.Les connecteurs clients Red Hat SSO permettent de sécuriser très facilement les applications et les services. Il fournit des adaptateurs pour un certain nombre de plateformes et de langages de programmation, mais s'il n'y en a pas un de disponible pour une plateforme choisie, il est possible d'utiliser n'importe quelle bibliothèque de ressources OpenID Connect SAML 2.0.

L'utilisation de RH SSO ne demande aucun frais, il suffit d'une installation et de quelques configurations pour mettre en place une base de la sécurité de ses applications.

2.3.2. FusionAuth

FusionAuth est une de seules solutions d'authentification, d'autorisation et de gestion des utilisateurs conçues pour les développeurs. Il se déploie sur n'importe quelle application en quelques minutes. Chaque fonctionnalité est présentée sous forme d'API, vous offrant ainsi une flexibilité totale pour gérer tous les cas d'utilisation. Ces fonctionnalités incluent l'authentification unique ou SSO, l'authentification à deux facteurs, les comptes d'utilisateurs multiples. FusionAuth offre un accès et contrôle à distance, l'authentification multi facteurs MFA, accès mobile et d'autres fonctionnalités.

Il est possible d'utiliser FusionAuth Cloud sur un autre hébergeur, vous achetez le service fusionAuth et l'héberger ailleurs ou vous choisissez le plan FusionAuth Community qui est gratuit et dispose des fonctionnalités d'authentification de base dont la plupart des applications ont besoin. FusionAuth offre également un service d'hébergement cloud FusionAuth Cloud, un support technique qui nécessite un abonnement.

FusionAuth est disponible dans plus de 12 pays, tous hors du continent Africain.

2.3.3. Okta

Créé en janvier 2009, Okta est une entreprise américaine basée à San Francisco. Okta est un service cloud de gestion des identités et des accès à la demande qui permet aux entreprises d'accélérer l'adoption sécurisée de leurs applications web, à la fois dans le cloud et derrière le pare-feu.

Les entreprises partout dans le monde se tournent rapidement vers les services de cloud tels que Salesforce, WebEx, Google Apps, Workday ou NetSuite pour alimenter leurs processus d'affaires. Elles ont besoin d'une solution pour les aider à adopter, déployer, sécuriser et gérer ces services. Cette solution devrait elle-même être construite à partir de zéro en tant que service fiable, évolutif, sécurisé et à la demande. Okta est ce service. En tant que service, Okta fournit une solution complète et clé en main qui répond aux besoins non seulement de l'informatique, mais aussi des utilisateurs finaux et des chefs d'entreprise - pas de travail de personnalisation ou d'engagement à long terme requis.

Okta dispose d'une version gratuite, d'une version d'essai gratuite et offre un abonnement. Ses clients types sont les auto entrepreneurs, les petites et moyennes entreprises et les grandes entreprises. Il est disponible en Australie, au Canada, en Chine, au Royaume Uni, en Inde et aux États unis.

Okta offre plusieurs fonctionnalités comme la gestion des utilisateurs, la reconnaissance automatique des utilisateurs, les notifications en temps réel, le stockage de mot de passe chiffré et bien d'autres.

2.3.4. Auth0

Auth0 est une plateforme cloud de gestion des identités conçue pour aider les entreprises de divers secteurs tels que la finance, la santé, les médias, la vente au détail et le tourisme à gérer en toute sécurité les activités de connexion, les profils d'utilisateurs et les identifiants. Auth0 à été créé en 2013 par Eugenio Pace et Matías Woloski. Ses fonctionnalités incluent les domaines personnalisés, l'authentification intégrée, SSO, le MFA, la migration de bases de données, la liaison de comptes, la rétention des journaux et la diffusion continue.

La plateforme permet aux développeurs de créer des informations de connexion universelles pour les employés et de contrôler les connexions sur les réseaux sociaux, l'authentification multifactorielle et la détection des anomalies pour les applications enregistrées. Auth0 comprend un tableau de bord de gestion des utilisateurs, qui aide les administrateurs à gérer la réinitialisation des mots de passe, les autorisations basées sur les rôles et la création/suppression des comptes utilisateur. Auth0 gère une base de données d'informations d'identification brassée, ce qui permet aux équipes de sécurité de vérifier et de bloquer les tentatives de connexion non autorisées en temps réel.

Auth0 s'intègre à diverses applications tierces telles que Salesforce, Box, Slack, Sentry, Zoom, Dropbox, Egnyte, Zendesk, CloudBees, etc. Le logiciel implémente des connexions sans mot de passe via un widget intégrable, qui authentifie automatiquement les utilisateurs en envoyant un OTP (One-time Password) par e-mail ou SMS ou via des notifications push et des capteurs biométriques. Les entreprises peuvent également connecter des applications sur différents appareils, ajouter ou supprimer des utilisateurs, configurer des règles d'accès et créer des pages de connexion personnalisées.

Auth0 est disponible dans plus de 119 pays et offre une version d'essai gratuite et un abonnement mensuel. Il vise principalement les Auto Entrepreneurs, les petites et moyennes entreprises et également les grandes entreprises.

NB: Depuis Mai 2021 les entreprises Okta et Auth0 ont fusionnées mais il reste cependant possible d'utiliser Auth0 indépendament de Okta; «Auth0 fonctionnera en tant qu'entité indépendante au sein d'Okta et restera dirigée par son CEO et cofondateur Eugenio Pace sous la supervision directe de Todd McKinnon, CEO et cofondateur d'Okta. Les deux plateformes continueront à exister en parallèle, sans interruption de maintenance ni d'investissements, l'objectif final étant de les intégrer au fil du temps. Cette fusion accélérera l'innovation et rendra la solution Okta Identity Cloud encore plus attrayante pour l'ensemble des clients et utilisateurs.» Tiré d'un article publié par Okta le 3 Mai 2021 sur son site internet okta.com.

2.3.5. AWS Cognito

Amazon Cognito est un service cloud appartenant à AWS (Amazon Web Services). C'est un logiciel de gestion des identités et des accès conçu pour aider les entreprises à gérer l'inscription des utilisateurs, leur connexion et l'accès aux applications mobiles et web via un portail unifié. La plateforme permet aux développeurs de se connecter à l'aide de fournisseurs d'identité d'entreprises tels que OpenID Connect et SAML 2.0 et de divers fournisseurs d'identité sociale tels que Amazon, Apple, Google et Facebook. Amazon Cognito prend en charge l'authentification multifactorielle et la fonctionnalité de cryptage des données et est conforme à diverses normes statutaires, notamment SOC, ISO/IEC, PCI DSS, HIPAA, etc. Les organisations peuvent personnaliser l'interface utilisateur avec des logos et des couleurs personnalisées pour établir l'identité de la marque. Les autres fonctionnalités comprennent un répertoire centralisé des utilisateurs, la gestion des accès, l'authentification adaptative, les autorisations basées sur les rôles, etc.

Conclusion

Une étude exhaustive de toutes les solutions de gestion des identités et des accès ne pouvant être faite dû à la pluralité des solutions sur le marché. Nous avons, cependant, suite à cette étude, une idée globale et déterminante des services fournis par les différents acteurs du domaine. Qu'il s'agisse de la solution RH-SSO de Redhat, de Okta et Auth0 qui ont fusionné ou de Amazon Cognito d'AWS, le principe reste quasi identique, ils offrent tous un service très bien fait qui répond aux besoins des entreprises de toute taille. FusionAuth quant à elle est l'une des rares solutions pensées pour les développeurs.

Nous avons également pu constater qu'à nos jours, ces solutions sont disponibles dans divers paysen dehors de l'Afrique mis à part Auth0 qui est disponible en Guinée-Bissau et en Afrique du Sud.

Nous conclurons donc que malgré l'existence d'une multitude de solutions de gestions des identités et des accès, clouds ou natives, le besoin d'une solution cloud de gestion des identités et des accès facilement intégrable par les développeurs et ou les entreprises ou professionnels, dans n'importe quelle application et surtout en afrique, demeure d'actualité. Nous pouvons affirmer que notre plateforme, non seulement trouvera sa place mais plus encore elle se démarquera par sa cible principale: les développeurs, et son emplacement(l'Afrique) qui n'est encore pas ou très peu couvert par les plateformes existantes.

3. Chap 3: Solution Proposée

Introduction

Après l'état de l'art sur les solutions de gestion des identités et des accès existantes, nous allons, dans ce chapitre, nous intéresser à l'étude de la solution que nous proposons. Nous allons dans un premier temps spécifier les besoins fonctionnels et non fonctionnels du système et identifier les acteurs. Nous procéderons par la suite à l'analyse et la conception des besoins fonctionnels et nous terminerons par la réalisation du système qui enveloppe l'implémentation, le déploiement et les tests de la solution. Dans cette partie nous apporterons également une justification du choix des technologies et outils adoptés pour l'implémentation de la solution.

L'analyse de la thématique et des différentes propositions existantes sur le marché ainsi que la compréhension des besoins des utilisateurs a permis de dégager les fonctionnalités qu'offre notre plateforme. Les contraintes auxquelles est soumis le système pour sa réalisation et son bon fonctionnement seront décrites par la suite comme étant des besoins non fonctionnels.

Deux types d'acteurs sont à identifier. Les acteurs qui interagissent directement avec notre système, c'est sont les acteurs principaux et les acteurs qui participent à la réalisation de certaines actions au sein de notre système plus communément appelés les acteurs secondaires.

Le développeur: c'est l'acteur qui s'inscrit sur la plateforme et ajoute ses applications.

Keycloak: intervient dans la réalisation de bon nombre des interactions des nos principaux acteurs avec le système.

Le système de paiement: qui intervient lors du paiement d'une facture ou lors de l'abonnement à un plan qui inclut le paiement d'une facture de 0 francs.

Dans cette partie, nous dégageons l'ensemble des besoins fonctionnels auxquels devra répondre notre solution cloud.

Les besoins fonctionnels et les attentes par rapport à notre plateforme varient suivant l'acteur.

Les besoins fonctionnels auxquels doit répondre notre plateforme se résume dans les points suivants:

c. Créer un client keycloak dans le realm du client inscrit à notre plateforme, à chaque fois que celui ci crée une application

Dans cette section, nous dégageons l'ensemble des besoins non fonctionnels auxquels devrait répondre notre plateforme.

Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance,de type matériel ou de type conceptuel. Ces besoins peuvent concerner les contraintes d'implémentation comme le langage de programmation, le type de la base de données, le type du provider, ....

L'ensemble des fonctionnalités à réaliser devront répondre aux besoins suivants:

a. Ergonomie de l'interface: L'application doit être facile à utiliser, les interfaces utilisateurs doivent être conviviales c'est à dire simples, ergonomiques et adaptées à l'utilisateur

b. Fiabilité: Il s'agit ici de la fiabilité de notre plateforme par rapport aux résultats qu'elle transmet aux clients lorsque ces derniers envoient une requête d'authentification.

c. Sécurité: La plateforme qui s'occupe de la sécurité des applications de ses clients doit elle-même répondre aux exigences de sécurité les plus strictes.

d. Scalabilité: Notre application doit être capable de fonctionner de manière optimale avec 1 ou 1 000 000 utilisateur(s). La scalabilité d'un service désigne la capacité de l'application et de l'infrastructure à s'adapter automatiquement pour traiter un niveau de sollicitation variable.

e. Élasticité: L'élasticité est la capacité d'ajuster les ressources à la hausse ou à la baisse automatiquement. Notre application doit pouvoir ajuster les ressources disponibles entre ses différents utilisateurs à la hausse tout comme à la demande, de façon à ce que chacun ait accès aux ressources nécessaires à ses besoins.

f. Résilience: On désigne par résilience la capacité d'un service à continuer de fonctionner malgré la défaillance d'un ou plusieurs composants (base de données, serveurs Web, accès réseau, ... ). La résilience désigne également la capacité du service à revenir dans un mode normal de façon automatisée. Notre application doit être en mesure de fournir son service à ses clients ce même en cas de défaillance d'un ou plusieurs de ses composants.

g. Performance : L'application doit être performante c'est-à-dire à travers ses fonctionnalités, répondre à toutes les exigences des usagers d'une manière optimale.

h. Mesurable: Le principe des plateformes cloud est le Pay As You Go c'est-à-dire que l'utilisateur ne paye que ce qu'il consomme et pour cela il doit être possible de mesurer sa consommation auprès de son fournisseur.

Une identification et une analyse méticuleuse des besoins fonctionnels est indispensable pour la réalisation d'une conception qui répond aux exigences de notre plateforme.

La connaissance des fonctionnalités à implémenter nous a permis d'établir le diagramme de cas d'utilisation de la plateforme.

Nous avons élaboré un diagramme de cas d'utilisation global dans lequel nous avons représenté des packages pour un souci de transparence et de lisibilité. Chaque package sera représenté de façon détaillée par la suite.

Nous avons jugé nécessaire de représenter les actions que notre système aura sur celui de keycloak dans un diagramme à part. Figure suivante.

Figure 3.2: Diagramme de cas d'utilisation illustrant les actions de notre système keycloak

Par la suite nous allons montrer les diagrammes détaillés de chaque package de notre diagramme de cas d'utilisation globale.

Cas d'utilisation: Pay Facture

Acteur: Développeur

Présentation: Le cas commence lorsque le développeur clique sur le bouton "payer facture"

Scénario Principal:

1. Déclenchement du cas «login»

2. Fin du cas «login»

3. Déclenchement du cas «pay facture»

4. Déclenchement du cas «choose payment mode»

5. Le mode de paiement est mobile money

Déclenchement du cas «mobile money»

5. 2. Le mode de paiement est carte bancaire

Déclenchement du cas «carte bancaire»

6. Redirige sur le «système de paiement»

Package: Abonnement

Acteur: Développeur

Présentation: Le cas commence lorsque le développeur clique sur le bouton "abonnement"

Scénario principal:

1. Déclenchement du cas «login»

2. Fin du cas «login»

3. Déclenchement du cas «membership»

4. Déclenchement du cas «view plan's list»

5. Fin du cas «view plan's list»

6. Déclenchement du cas «choose plan»

7. Fin du cas «choose plan»

8. Déclenchement du cas «view plan's details»

9. Fin du cas «view plan's details»

10. Déclenchement du cas «subscribe to plan»

11. Déclenchement du cas «pay facture» (0 francs )

12. Fin du cas «pay facture»

13. Fin du cas «subscribe to plan»

14. Fin du cas «choose plan»

15. Fin du cas «membership»

Cas d'utilisation: Add Users

Acteur: Développeur

Présentation: Le cas commence lorsque le développeur clique sur «add user»

Scénario Principal:

1. Déclenchement du cas «login»

2. Fin du cas «login»

3. Déclenchement du cas «add users»

3.1. Le mode d'ajout d'utilisateurs est la fédération des utilisateur

Déclenchement du cas «user federation»

3.2. Le mode d'ajout est le chargement de fichier

Déclenchement du cas «file upload»

4. Déclenchement du cas «authentication Mode»

4.1. Le mode d'authentification est le mode API

4.2. Le mode d'authentification est le mode Redirection

5. Déclenchement du cas "Mode de Facturation"

6. Déclenchement du cas "Mode de Payement"

Scénario Alternatif

5. a. Le client choisit de prendre un abonnement.

Cas d'utilisation: Send auth request

Acteur: App-client

Présentation: Le scénario commence lorsque le n-user d'une application demande à accéder à une ressource de l'application

Scénario Principal:

a. L'application s'authentifie auprès du système

Déclenchement du cas «authenticate»

BLe système valide l'authentification

1. L'application envoi la requête d'identification

Déclenchement du cas «send auth request»

2. Le mode d'authentification est «redirect mode»

Déclenchement du cas «redirect mode»

3. Le système renvoie une réponse à l'application

Le diagramme de classe nous a permis d'identifier les différentes entités de notre système et leurs relations.

L'architecture d'un projet est vitale pour la vie du projet lui-même et comment celui-ci sera en mesure de faire face à l'évolution des nouveaux besoins à l'avenir. Les avantages d'une architecture propre et bien pensée sont nombreuses, en voici quelques unes:

a. Une architecture bien pensée nous permet d'obtenir un code propre et lisible

b. Dans une bonne architecture, les morceaux de code sont réutilisables dans l'application

c. On peut éviter les répétitions en mettant en place une architecture adaptée.

d. L'évolution d'une application dont l'architecture est bien pensée est beaucoup plus facile.

Dans ce projet, nous avons opté pour une architecture trois tiers. L'idée est d'utiliser le principe de séparation des préoccupations pour éloigner la logique métier des routes de l'application.

La couche de données: Dans l'architecture 3-tiers, comme en MVC, la couche donnée réside dans ses propres modules.

Le but est de découper la logique métier des opérations de base de données. Ainsi, il est possible de faire évoluer le métier et la base de données séparément.

La couche métier: Cette couche implémente les algorithmes "métier" de l'application. Elle est indépendante de toute forme d'interface avec l'utilisateur. Ainsi elle doit être utilisable aussi bien avec une interface console, une interface web, une interface de client riche. Elle doit ainsi pouvoir être testée en dehors de l'interface web et notamment avec une interface console. C'est généralement la couche la plus stable de l'architecture. Elle ne change pas si on change l'interface utilisateur ou la façon d'accéder aux données nécessaires au fonctionnement de l'application.

La couche de présentation: Cette couche est l'interface (graphique le plus souvent) qui permet à l'utilisateur de piloter l'application et d'en recevoir des informations.

Nous pouvons maintenant discuter de ce qu'on appelle habituellement le flux de la structure de l'application. Le flux de la structure applicative est un ensemble des règles et des pratiques courantes à adopter lors du développement d'une application. Express.js est un excellent framework pour node.js, mais il ne vous donne aucune indication sur la manière d'organiser votre projet node.js, c'est sont donc là, les résultats d'une recherche approfondie sur les méthodes de codages de personnes expérimentées avec les technologies node.js/express.js qui seront adoptés.

Tout doit avoir sa place dans notre application, alors les dossiers sont l'endroit idéal pour regrouper les éléments communs. En particulier, nous voulons définir une séparation très importante entre les modules de notre application, ce qui nous amène à la règle n°2.

Règle n ° 2: garder une séparation claire entre la logique métier et les routes

Les frameworks comme Express.js sont incroyables. Ils nous fournissent des fonctionnalités incroyables pour gérer les demandes, les vues et les itinéraires. Avec un tel support, il pourrait être tentant pour nous d'intégrer notre logique métier dans nos routes. Mais cela induit rapidement des blocs monolithiques géants qui se révéleront ingérables, difficiles à lire.

La testabilité de notre application diminuerait, et par conséquent le temps de développement devient plus long. « Comment pouvons-nous résoudre ce problème, alors? Où mettre notre logique métier de manière claire et intelligente? » La réponse est révélée dans la règle n°3.

C'est ici que doit vivre toute notre logique métier. Il s'agit essentiellement d'un ensemble de classes, qui implémentent la logique de base de notre application, chacune avec ses méthodes. Je préfère que les classes soient fusionnées avec les modèles.

Les « lib » présentent notre bibliothèque qui sont des fonctions (plus ou moins des middleware) prédéfinis dans notre application tel que connexion mongo, authentification, logger, security etc...

Maintenant que nous avons défini ces trois règles initiales, nous pouvons représenter graphiquement le résultat comme ceci:

D'après ce graphique nous aboutissons à l'arborescence suivant pour notre application:

En UML, Les diagrammes de composants sont utilisés pour visualiser l'organisation des composants du système et les relations de dépendance entre eux. Ils fournissent une vue de haut niveau des composants d'un système. Les composants peuvent être un composant logiciel tel qu'une base de données ou une interface utilisateur ; ou un composant matériel tel qu'un circuit, une micropuce ou un dispositif ; ou une unité commerciale telle qu'un fournisseur, un service de paie ou d'expédition.

En UML, un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux. Les éléments utilisés par un diagramme de déploiement sont principalement les noeuds, les composants, les associations et les artefacts. Les caractéristiques des ressources matérielles, physiques et des supports de communication peuvent être précisées par stéréotype.

Ayant opté pour une application cloud, il est donc impératif de choisir le provider qui héberge notre application.

Les fournisseurs cloud étant nombreux, nous allons faire une étude comparative et choisir le provider le mieux adapté; l'étude va se porter sur les 4 providers suivants: Redhat, Amazon Web Services, Microsoft Azure et Google Cloud Platform. Les critères d'études sont les suivants:

a. Système d'exploitation OS: ce critère vise à identifier les différents systèmes d'exploitations pris en charge par chacun des providers.

b. Facilité et rapidité d'accès: la rapidité et la facilité d'accès des services d'un provider cloud se détermine par la proximité de ses datacenters DC. Ce critère est l'un des plus indispensable dans une étude comparative des providers cloud.

c. Coût: un service cloud est mesurable donc a un coût. Nous allons nous attarder sur les coûts proposés par les différents fournisseurs.

d. SLA Service-Level Agreement: est un accord entre un fournisseur de services cloud et un client qui assure le maintien d'un niveau de service minimum. Il garantit les niveaux de fiabilité, de disponibilité et de réactivité des systèmes et des applications, précise qui est responsable en cas d'interruption de service et décrit les pénalités en cas de non-respect des niveaux de service.

f. Failover: le failover, ou basculement est un mode de fonctionnement de secours qui consiste à basculer automatiquement sur une base de données, un serveur ou un réseau placé en attente si le système principal tombe en panne ou est arrêté le temps d'une maintenance.

g. Langages: nous identifions les langages de programmation pris en charge par chacun des providers.

h. Security: Nous nous intéressons ici, à qui revient la responsabilité du service entre le client et le fournisseur.
Voyons ci-dessous le tableau comparatif des provider:

a. Node js: Node.js est une plateforme logicielle libre en JavaScript, orientée vers les applications réseau événementielles hautement concurrentes qui doivent pouvoir monter en charge. Ce qui est le cas de notre application.

Node.js est un système single thread non bloquant: Ce qui veut dire qu'il n'attend pas la fin d'exécution d'une requête pour en traiter une autre.

Cela octroie une certaine rapidité aux applications qui font beaucoup de requêtes car Node.js est capable de gérer énormément de requêtes en parallèle sans les faire attendre les unes les autres.

Node.js est flexible: Node.js est très light comme plateforme et n'a pas beaucoup de fonctionnalités déjà intégrées. Ce qui nous donne le choix des modules à lui greffer pour l'utiliser.

Il n'y a pas de conventions strictes sur comment s'y prendre, cela nous laisse pas mal de marge de manoeuvre pour décider de tout. Ce qui fait qu'il est possible de commencer avec quasiment rien et avancer petit à petit dans la direction qu'on pense être la meilleure au fur et à mesure que nous avançons dans ton projet.

Node.js c'est du javascript: Bien souvent il peut s'avérer un peu déstabilisant de coder avec un langage du côté front-end et un autre langage du côté back-end, avec Node.js ce casse-tête est fini parce qu'on reste dans le même langage partout. Au niveau organisation du code, c'est encore mieux. On pourra avoir les mêmes conventions de noms, les mêmes bonnes pratiques dans tout le code de notre projet, aussi bien en Front qu'en Back.

b. Le framework Express JS: Express js est un framework utilisé pour construire des applications web basées sur node.js. C'est le plus populaire de tous les framework node.js et il est doté d'une prise en main très facile. C'est de fait le framework standard de node.js.

c. MySql: MySQL est un système de gestion de base de données relationnelle (SGBDR) open source, basé sur le langage SQL (Structured Query Language). Cette solution, parmi les plus populaires au monde, est connue pour délivrer de hautes performances dans le stockage de larges volumes de données (notamment dans le big data) ou la Business Intelligence. Fondé en 1994, MySQL a été racheté par Sun Microsystems en 2008 et appartient à Oracle Database depuis 2010. MySQL est utilisé par de nombreuses entreprises dans le monde, dont Google, Yahoo!, YouTube, et Adobe, dans le digital, Airbus, Alstom, et Alcatel-Lucent dans l'industrie, Crédit agricole, dans le secteur de la banque et de l'assurance, ....

d. Docker: Docker est une plateforme logicielle virtualisée de système lancée en 2013 ayant largement contribué à la démocratisation de la conteneurisation. Elle permet de créer, déployer et exécuter facilement des applications dans des conteneurs. Il en existe d'autres, mais celle-ci est la plus utilisée. Elle est par ailleurs plus facile à déployer et à utiliser que ses concurrentes. Le fonctionnement de Docker repose sur le noyau Linux et les fonctions de ce noyau, comme les groupes de contrôle cgroups et les espaces de nom. Ce sont ces fonctions qui permettent de séparer les processus pour qu'ils puissent s'exécuter de façon indépendante.

En outre, Docker permet d'automatiser le déploiement des applications au sein d'un environnement de conteneurs. Grâce à ces divers outils, les utilisateurs profitent d'un accès complet aux applications et sont en mesure d'accélérer le déploiement, de contrôler les versions et de les attribuer.

a. Star UML pour la modélisation des diagrammes: StarUML est un logiciel de modélisation UML (Unified Modeling Language) open source qui peut remplacer dans bien des situations des logiciels commerciaux et coûteux comme Rational Rose ou Together . Étant simple d'utilisation, nécessitant peu de ressources système, supportant UML 2, ce logiciel constitue une excellente option pour une familiarisation à la modélisation.

b. Git et Github pour le versionning et le dépôt: Git est un logiciel de versionning gratuit et open source. GitHub est un service d'hébergement de référentiel open source.Il héberge vos projets de code source dans une variété de langages de programmation et garde une trace des différentes modifications apportées à chaque itération.

c. Visual Studio Code pour l'écriture du code: Visual studio code ou VS Codeest un éditeur de code développé par Microsoft en 2015 et est développé avec le framework Électron et conçu principalement pour développer des projets avec Javascript, Node.js ou encore TypeScript. Le choix a été donc très facile

d. Figma pour la conception des wireframes: Figma est une plateforme web collaborative qui permet la création d'interfaces pour le web et le mobile. Nous l'avons utilisé pour construire nos wireframes et les schémas explicatifs. Le choix s'est porté sur figma pour sa simplicité et son coût qui est gratuit contrairement à bon nombre de ses concurrents.

Dans les sections précédentes de ce chapitre, nous avons eu à étudier notre solution dans tous ses contours. Nous avons spécifié les besoins fonctionnels et non fonctionnels tout en mettant en avant les différentes fonctionnalités de l'application et en décrivant les interactions des utilisateurs avec le système. Nous avons également fait l'analyse et la conception des besoins fonctionnels et le choix des différents outils et technologies a été mis au clair.L'architecture de l'application a également été dégagée.

La page d'accueil est la page sur laquelle tout visiteur est amené à voir en premier lorsqu'il visite notre application. Cette page présente notre application en expliquant le service et les fonctionnalités offert.

A partir de cette page, un utilisateur peut se connecter pour accéder à son espace client.

Si un utilisateur n'a pas de compte il peut en créer un pour ainsi bénéficier de nos services.

a. Informations de l'application: Sur cette partie le client renseigne les informations basiques de son application comme le nom, les technologies utilisées et une description éventuelle.

b. Providing des utilisateurs: Ici, le client spécifie de quelle manière il va nous fournir les utilisateurs. Il pourra choisir parmi les deux méthodes disponibles.

c. Mode d'authentification: Le client va ensuite choisir un mode d'authentification pour ses utilisateurs: soit ces derniers restent sur son interface à lui, soit ils sont redirigés sur notre interface et seront renvoyés sur son application après authentification.

d. Mode de facturation et mode de paiement: En dernière étape, le client choisit un mode de paiement et de facturation pour son application; à ce stade seul le mode de facturation PAYG et le mode de paiement par mobile money sont disponibles.

Après l'ajout si tout s'est bien passé on lui affiche un récapitulatif de ses informations et un fichier de configuration à télécharger.

Dans cette partie nous passons au déploiement de notre plateforme. Nous avons, plus haut dans la partie conception, fait le choix de notre provider qui s'est porté sur AWS.

Nous allons conteneurisé notre application avec docker et le déployer sur le service EKS d' AWS qui est un service géré utilisé pour exécuter Kubernetes sur AWS sans avoir besoin d'installer, d'exploiter et de maintenir un plan de contrôle ou des noeuds Kubernetes.

Commençons par installer AWS CLI en ligne de commande. Pour cela tapons la commande suivante dans le terminal:

Maintenant, créons un Dockerfile pour construire notre application Express dans une image de conteneur :

Nous allons taguer puis pousser notre image vers notre registry ECR créé sur AWS.

Un cluster Kubernetes est un ensemble de machines nodales permettant d'exécuter des applications conteneurisées. L'usage de Kubernetes implique l'usage d'un cluster.

Maintenant que l'image est poussée vers le repository ECR, la manière la plus simple de la déployer vers le cluster est d'utiliser la console aws.

En premier lieu, nous allons configurer kubectl à cet effet nous faisons recours à docker desktop.

Nous allons maintenant créer un déploiement. Un Deployment indique à Kubernetes comment créer et mettre à jour les instances de notre application. Une fois que nous avons créé un Deployment, le maître Kubernetes planifie les instances de l'application incluses dans ce Deployment pour qu'elles s'exécutent sur les différents noeuds du cluster. Dans Kubernetes, un service est une abstraction qui définit un ensemble logique de pods et une politique permettant d'y accéder. Les services permettent un couplage souple entre les pods dépendants.

Ici, nous allons ajouter le déploiement et le service dans un seul fichier manifest.yml :

Pour configurer keycloak et le déployer sur notre EKS, nous sommes passé par un fichier de configuration : deployment.yaml

Ce fichier contient à la fois les configurations pour le déploiement et le service qui seront utilisés par EKS. Nous allons maintenant le pusher vers notre EKS.

Nous avons créé et configuré un cluster sur Amazon EKS dans lequel nous avons déployé notre application dockeurisée pusher dans un registry sur ECR. Puis nous avons configuré et lié une base de données Amazon RDS à notre application et nous avons déployé keycloak sur notre cluster. Après toutes ces étapes, notre application tourne maintenant sur notre cluster et on peut le constater sur l'image suivante.

Conclusion

Tout au long de ce troisième chapitre, nous avons eu à présenter et expliquer notre environnement de travail. Nous avons ensuite élaboré notre architecture logicielle pour enfin présenter les parties essentielles de l'implémentation de notre plateforme. Nous avons également pu expliquer les différentes étapes pour le déploiement de notre application avec des illustrations, et nous avons enfin pu tester notre application en ligne.

4.1. Conclusion:

Ce projet de fin d'études avait pour ambition d'établir une plateforme cloud de gestion des identités et des accès basée sur l'outil Keycloak, en se demandant si celle-ci permettrait aux développeurs, spécialistes et entreprises de manière générale, de réaliser des applications plus sécurisées en moins de temps et de configurations.

L'étude ci-dessus nous a permis d'avoir une vue assez large sur les solutions cloud de gestion des identités et des accès.

Nous avons, en premier lieu, mis en contexte le projet et dégagé la problématique.

Il a fallu ensuite s'intéresser à la gestion des identités et des accès d'une manière assez générale et globale ainsi que de l'outil keycloak qui est au coeur de notre plateforme afin de donner une vue globale de ses fonctionnalités et des protocoles sur lesquels il se base.

Après cela, il convenait d'établir une étude sur les solutions existantes, étude qui s'est portée sur cinq solutions et qui a abouti en une conclusion assez tranchante quant à la la pertinence d'une solution cloud de gestion des identités et des accès basée sur un outil d'IAM, keycloak, pensée développeurs et surtout facilement accessible en milieu Africain.

Notre plateforme a permis de développer des applications plus sécurisées, car le maillon le plus important et le plus vulnérable de toute application est désormais géré en dehors de l'application par keycloak. Le développeur ou le spécialiste n'ayant besoin de rien installer, ni d'une multitude de fichiers de configurations, il bénéficie d'un gain énorme de temps dans le développement de ses applications. Il peut également se passer de l'écriture des interfaces de login (sauf dans le cas où il voudrait implémenter sa propre interface) et de l'implémentation d'un module complexe de gestion des utilisateurs.

Toujours dans le souci de faciliter la gestion des utilisateurs, il serait intéressant d'avoir un sdk à la place du fichier de configuration ou des variables d'environnement.

Notre projet comme tout bon projet d'ingénierie ne s'arrête pas ici, il fera l'objet de mise à jour au fur à mesure de l'évolution des technologies de gestion des identités et des accès et des technologies de cloud computing. Mais en attendant voyons ensemble quelques évolutions qui suivront très vite dans la partie qui suit.

4.2. Perspectives:

Notre projet est, on l'a vu tout au long de ce mémoire, très ambitieux et s'attaque à une des parties les plus fondamentales et vulnérables de toute application. Ceci étant, il a été possible de développer les bases essentielles pour une bonne gestion des utilisateurs durant le temps imparti. Nous allons, dans cette partie, voir les perspectives de notre projet dans un futur très proche.

Les fonctionnalités seront intégrées dans l'application dans la prochaine version de notre plateforme:

? à partir d'une api(pour du json donner les clés à utiliser, pour le xml les balises)

? Définir une black liste (pour empêcher des utilisateurs spécifiques de se connecter)

Bibliographie

GUILLAUME Harry, IAM - Gestion des identités et des accès : concepts et états de l'art, HAL hal-00879556f, 2013, 59 pages.

LESSARD Michael, Introduction à RH-SSO - Centraliser la gestion d'identité et sécuriser vos applications, Redhat, 2022, 37 pages.

LONGUET Delphine, UML, Polytech Paris-Sud Formation initiale 3e année Spécialité Informatique, Année 2016-2017

DIALLO Mamadou Cellou Etude et Mise en place d'une plateforme de mise en relation entre particuliers et prestataires dans le domaine du service domestique, ISI, 2020-2021, 72 pages.

SARI Moulay Ali Réalisation d'un système de réservation d'hébergement en ligne, Université Abou Bakr Belkaid- Tlemcen, 2017-2018, 56 pages.

PRAKASH AdityaAmazon EKS: Deploying a NodeJS app using Docker and K8s on AWS, GeekyAnts, 09/04/2021, 8 minutes de lecture.

SIMPSON Josh Using AWS RDS with Node.js and Express.js, Stackabuse, 29/01/2020, 11 minutes de lecture.