S’il fallait résumer les avantages de la solution OAuthSD + ARAMIS, le mieux serait :
La conjonction d’OAuthSD et d’ARAMIS permet d’assurer l’authentification des utilisateurs par les applications extérieures, sans procédure de login/mot de passe, tout en sanctuarisant les données sensibles des utilisateur sur le réseau interne de l’entité, sans rien changer à ces données, les comptes et les droits restant gérés exclusivement par ARAMIS.
Les avantages vont donc bien au-delà d’un simple système de connexion unique (Single Sign On, SSO).
La gestion des utilisateurs est effectuée exclusivement par Aramis
Dans cette configuration, c’est le système Aramis qui gère les données relatives aux utilisateurs et fournit l’User ID : Le serveur OAuthSD fonctionne avec la table ’users’ vide !
L’identifiant de l’utilisateur final est fourni par le système Aramis. C’est cet identifiant qui figurera dans la déclaration ’sub’ du jeton d’identité JWT.
OAuthSD permet donc d’intégrer un système d’identification existant sans nécessité d’une double maintenance ou d’une synchronisation des tables des utilisateurs.
Incorporation des données Aramis dans le jeton d’identité JWT
OAuthSD permet d’incorporer dans le jeton d’identité des données supplémentaires issues d’Aramis. Le mécanisme général est décrit ici : Incorporer au jeton JWT des déclarations supplémentaires.
Un système d’identification xxx propre à une application OAuthSD dédiée est intégré au moyen d’un script /oidc/identification/xxx/login.php particulier. Ce script place les données de l’utilisateur issues du système dans une variable de session $_SESSION[’user_claims’], sous forme cryptée.
Les données seront automatiquement incorporées au jeton d’identité JWT sous la forme d’une déclaration supplémentaire pour chaque membre de premier niveau de l’array ’user_claims’.
Il est ainsi possible de passer de façon sûre des données de profil de l’utilisateur final authentifié qui permettront aux applications destinataires du jeton JWT de gérer l’accès en fonction des droits de l’utilisateur qui auront été définis au niveau d’Aramis.
Userinfo
La table users étant vide, le contrôleur UserInfo ne peut retourner les données de l’utilisateur sans modification du code. Si nécessaire, un nouveau contrôleur UserInfo devra être créé pour retourner les données extraites de la carte Aramis. Notons cependant que la fonctionnalité Userinfo ne faisant pas partie du "standard" OpenID Connect, le serveur OAuthSD est donc conforme en l’état.
Le développement réalisé pour la CRAMIF
L’objectif de la CRAM Ile-de-France (CRAMIF) était de sécuriser la connexion des utilisateurs de son application de signature électronique, le SAAS Web "Lex Persona", à partir des postes de travail internes aussi bien que depuis le Web. Pour cela, nous avons installé notre serveur OpenID Connect "OAuthSD" sur l’infrastructure informatique de la CRAM Ile-de-France (CRAMIF).
Le système d’identification par carte "Aramis" a été intégré au serveur OAuthSD : les utilisateurs sont gérés par le système existant, et les autorisations pré-établies des différents acteurs sont automatiquement intégrées au jeton d’identité et transmises à Lex Persona au moyen de celui-ci.
Notons que cette technique dispense totalement l’utilisateur de tout dialogue de connexion, ce qui procure un confort et un gain de temps appréciables.
OAuthSD peut intégrer tout pourvoyeur d’identité
La structure modulaire d’OAuthSD permet d’intégrer tout pourvoyeur d’identité, Aramis n’étant qu’un exemple.
Il est également possible d’intégrer plusieurs systèmes simultanément.
En particulier, remarquant qu’une identification par carte identifie la carte, pas le porteur, il est opportun de demander une deuxième authentification (TFA), cette dernière requérant un élément dans la possession de l’utilisateur à authentifier.