Sans persistance de l'authentification

...

• Le stockage du trio token, login et rôles en base Mongo permet au backend de récupérer le login ou les rôles depuis le token fournit par l’utilisateur. Cela permet de consolider la sécurité en évitant qu’un utilisateur malveillant ne manipule son login ou la liste de ses rôles.

• Lorsque on enregistre un trio token, login et rôles en base Mongo une date-heure est mise à jour pour l’entrée concernée. Cela permet de nettoyer à terme les entrées considérées comme inactives depuis trop longtemps (la durée est configurable mais idéalement il est conseillé de mettre le temps d’expiration du token TGT).

Avec persistance de l'authentification

Enregistrement de l’authentification

L’enregistrement du couple login / mot-de-passe est déclenché lors de l’authentification réussie d’un utilisateur si le paramètre d’enregistrement est activé.

Image Added 

La clé de chiffrement est générée côté serveur puis “oubliée” dans la foulée (elle est transmise à l’application mobile au travers du payload du token JWT renvoyé en réponse à l’authentification).

L’UUID correspond à la clé primaire du couple login / mot-de-passe stocké en base de données.

Utilisation d’une authentification préalablement enregistrée

Lorsque l’on souhaite se ré-authentifier, il suffit à l’application mobile cliente de récupérer le JWT dans le Secure Storage et de l’envoyer au serveur. Ce dernier utilisera alors l’UUID+clé contenus dans le payload afin de déchiffrer le couple login / mot-de-passe et de le soumettre au serveur CAS pour ré-authentifier l’utilisateur.

 Image Added

A noter

• Le chiffrement du couple login / mot-de-passe en base Mongo se fait selon l’algorithme AES-256. Il s’agit d’un chiffrement logiciel avant l’insertion de l’entrée en base, la base Mongo en elle même n’est pas chiffrée.

• Chaque couple login / mot-de-passe utilise une clé de chiffrement différente.

• Le serveur ne stocke pas les clés de chiffrement.

• Ce système permet à un utilisateur d’enregistrer son authentification indépendamment sur plusieurs téléphone ou tablettes. Chaque appareil aura un UUID différent.

• Lorsque on enregistre un couple login / mot-de-passe ou lorsqu’on en utilise un pour se ré-authentifier une date-heure est mise à jour pour l’entrée concernée en base Mongo. Cela permet de nettoyer à terme les entrées considérées comme inactives depuis trop longtemps (Cas d’un appareil perdu, d’une application désinstallée, etc…)

Implémentation et comportement de la réauthentificiation au niveau de l'App Frontend

L’application cliente dispose d'un intercepteur HTTP (shared/.../auth/auth.interceptor.ts) pour les erreurs HTTP 401 (non autorisé) retournées par le backend.

Toutes les requêtes retournant une 401 sont interceptées et une ré-authentification est effectuée si le mot de passe avait été sauvegardé (sauf lors d’une tentative de login de l’utilisateur qui aurait échoué)

Exemple : sur une page lançant plusieurs requêtes nécessitant chacune l’envoi du token de l’utilisateur, si le token a expiré, ces requêtes se terminent en 401. L'intercepteur traite la première d'entre elles et entraîne une ré-authentification pendant que les autres restent en attente du résultat.

Si la ré-authentification réussit, ces requêtes sont automatiquement relancées et les résultats sont renvoyés aux observables correspondants.

Si la ré-authentification échoue (ou que l'utilisateur n'avait pas choisi de sauvegarder ses identifiants), le profil anonymous (= non authentifié) est chargé.

Les erreurs 401 ne sont plus interceptées par le app.error.handler tant que l'intercepteur est activé.

Pour l’utilisateur ayant sauvegardé ses identifiants la ré-authentification est donc invisible même si il elle se fait lors d’un changement de page. Cela est également valable lors de l'ouverture de l'app si le token a expiré depuis sa dernière visite.