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

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.

2.1. Concepts de base

2.1.1. JWT

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

Figure 2.1: Processus de génération d'une JWT

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:

Figure 2.2: Différentes parties d'une JWT

? 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.

Ainsi, voici à quoi ressemblera notre JWT :

Figure 2.3: Exemple d'une JWT

2.1.2. Access token

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.

2.1.3. Refresh token

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.