« Authentification OpenID par Authelia » : différence entre les versions
Ligne 24 : | Ligne 24 : | ||
* Prénom NOM (scope <code>profile</code>); | * Prénom NOM (scope <code>profile</code>); | ||
* groupes Sigma dont l'utilisateur est membre (scope <code>groups</code>). | * groupes Sigma dont l'utilisateur est membre (scope <code>groups</code>). | ||
Lorsque votre backend reçoit ces informations après une authentification réussie avec Authelia, il est conseillé de créer votre propre session utilisateur en émettant un JSON Web Token (stocké dans un cookie <code>HttpOnly</code>, pour les sites avec Server-Side template Rendering), un Opaque Access Token (pour les sites avec un frontend et un backend séparés). | |||
==Example d'implémentation== | ==Example d'implémentation== |
Version du 16 février 2024 à 06:51
L'annuaire des utilisateurs Sigma est disponible pour l'authentification auprès de sites binets tiers à travers le protocole OpenID.
Le serveur d'authentification est situé à l'adresse auth.binets.fr et est une instance Authelia.
Pour permettre à votre site de bénéficier de ce moyen d'authentification, faites un ticket Panix en précisant l'url complète de callback vers laquelle Authelia redirigera l'utilisateur après une connexion réussie. La demande doit être justifiée, suite à quoi un BRman ajoutera votre site à la liste des bénéficiaires autorisés.
Comment ça marche ?
Lorsqu'un utilisateur souhaite s'authentifier, voici les actions qui devront être réalisées par votre site :
- Un bouton de Login de votre frontend fait une requête à votre backend.
- Votre backend renvoie une redirection vers Authelia à l'aide d'un client OpenID (de nombreux packages sont disponibles dans tous les langages de programmation à cet effet).
- L'utilisateur sera alors redirigé vers Authelia pour s'authentifier. S'il l'est déjà (session Authelia valide existante), cette étape sera passée.
- Après authentification, Authelia redirigera l'utilisateur vers la route de votre backend précisée en tant que
callback url
dans la configuration d'authelia, en envoyant en prime des données liées à cet utilisateur (nom, email...). - Votre backend reçoit ces données, et crée une session propre à votre site pour cet utilisateur (session, JSON Web Token, Opaque Access Token...). Lorsque cette session propre à votre site expirera, l'utilisateur pourra à nouveau d'authentifier via Authelia pour la renouveler.
Informations disponibles (scopes)
Authelia met à disposition différentes données utilisateur à travers des scopes
.
Lors de la configuration du client OpenID dans votre backend, vous devrez préciser les scopes auquels vous souhaitez accéder afin de recevoir les données correspondantes. Le scope openid
est obligatoire.
Les informations suivantes sont mises à votre disposition :
- email (scope
email
); - Prénom NOM (scope
profile
); - groupes Sigma dont l'utilisateur est membre (scope
groups
).
Lorsque votre backend reçoit ces informations après une authentification réussie avec Authelia, il est conseillé de créer votre propre session utilisateur en émettant un JSON Web Token (stocké dans un cookie HttpOnly
, pour les sites avec Server-Side template Rendering), un Opaque Access Token (pour les sites avec un frontend et un backend séparés).
Example d'implémentation
Pour Node.js et Adonis JS
Le protocole OpenID est très commun, et de nombreux packets existent qui nous simplifieront la vie. Pour tous les backend basés sur Node.js (Adonis JS, nest.js, Express...), il est possible d'utiliser le packet openid-client.
Voici un example pour Adonis JS, qui s'adapte à tout backend basé sur Node.js, sur Gitlab.
Cette implémentation nécessite:
- Qu'une route (comme
/auth/sigmaUser/login/
) pointe vers la fonctionloginSigmaUser
- Que la route
/auth/sigmaUser/callback/
pointe vers la fonctioncallbackSigmaUser
- Une base de données avec trois colonnes: state, codeVerifier et date de création
- Un cron (fonction qui s'éxécute régulièrement, par exemple une fois par jours) qui supprime les lignes de la base de donnée susnommée qui sont trop vieilles (par exemple vieilles de plus d'une heure). Voir l'implémentation du cron (qui est ici exécuté lorsqu'un autre programme fait une requête à une certaine route)
Le cron est nécessaire, car si un utilisateur commence à se connecter, une nouvelle ligne est crée dans la base de données. Elle est ensuite supprimée lorsqu'il a tapé ses identifiants. Si l'utilisateur ne tape jamais ses identiiants, la ligne n'est jamais supprimée, d'où la nécessité du cron.
Utilisation du serveur Authelia de test
L'exemple précédent utilise le serveur réel du BR, mais il est préférable d'utiliser un serveur de test sur ton ordinateur pendant que tu développes.
Pour ce faire, clone ce repo sur ton pc.
L'adresse du serveur d'authentification devient alors http://localhost:9091
au lieu de https://auth.binets.fr
(il faut donc changer la variable AUTH_URL
de l'exemple précédent)
Pour lancer le serveur de test fait docker compose up