« Authentification OpenID par Authelia » : différence entre les versions
Aucun résumé des modifications |
|||
Ligne 6 : | Ligne 6 : | ||
==Comment ça marche ?== | ==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 [https://auth.binets.fr 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 [https://auth.binets.fr Authelia] pour s'authentifier. S'il l'est déjà (session Authelia valide existante), cette étape sera passée. | |||
* Après authentification, [https://auth.binets.fr Authelia] redirigera l'utilisateur vers la route de votre backend précisée en tant que <code>callback url</code> 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== | ==Informations disponibles== |
Version du 16 février 2024 à 06:41
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
Les informations disponibles sur authelia pour un utilisateur sont :
- email ;
- uid ;
- Prénom NOM ;
- groupes Sigma (seulement les groupes dont on est membre).
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