Centralised Authentication Server et self-hosting

a marqué ce sujet comme résolu.
Auteur du sujet

Bonjour,

Je souhaite depuis longtemps me lancer dans le self-hosting (plus qu’un simple lecteur RSS qui dure quelques mois) mais ce que je remarque à chaque fois est l’authentification qui n’est pas centralisé. Ça semblerait pourtant logique d’avoir un service qui gère l’authentification et les autres qui en dépendent.

Pour ceci, LDAP semble se développer (en tout cas plus que les autres solutions) cependant son approche me semble très mauvaise : de ce que j’en vois, ça ressemble beaucoup à une sorte de base de données d’informations utilisateurs que chaque service utilise à la création/connexion/édition de compte. Une approche comme un CAS semble plus adapté car il simplifie la gestion utilisateur de chaque application : si une requête sans le bon cookie est effectué, on redirige l’utilisateur vers le serveur d’authentification qui fournira un token au client. Ça décharge chaque service de toute gestion d’authentification, qui est souvent très (trop) répétitive et similaire entre services self-hosted.

Un schéma complet de l’exécution est disponible. Pour résumer :

  1. L’utilisateur essaie d’accéder à l’application 1 mais n’est pas authentifié donc se fait rediriger vers le serveur d’authentification.
  2. En se connectant à l’aide d’un formulaire, un cookie sur le CAS est créé, nommons le TGT et l’utilisateur reçoit un ticket.
  3. L’utilisateur accède donc à nouveau à l’application, en fournissant ce ticket cette fois. L’application demande au CAS si le ticket est valable, puis établi un cookie ce qui évite au client de fournir le ticket à chaque fois.
  4. L’utilisateur essaie d’accéder à une seconde application protégée, qui refuse sa demande et le redirige vers le CAS.
  5. Le CAS sait que le client est déjà authentifié (merci le cookie TGT) et lui fournit un ticket pour la seconde application.
  6. Cf étape 3. :)

Ça me semble donc très adapté à du self-hosting : les services n’ont plus d’authentification à gérer. L’approche LDAP oblige les applications à gérer l’authentification, elles ne stockent juste plus les données dans leurs propres bases de données. Le seul avantage à LDAP que je vois est que ça permet une plus grande intégration entre les apps : elles peuvent partager des données sur les profils. Cependant, c’est utile uniquement dans un domaine ou les applications s’entremêlent, ce qui est rare dans les services classiques qu’on peut vouloir héberger pour un usage personnel.

Étant donné la faible étendu de CAS hors le domaine de l’entreprise et de l’éducation (mon école utilise ça), je dois rater un truc ? Je n’ai trouvé qu’une unique implémentation digne de ce nom, celle de référence. Je rate peut-être un inconvénient majeur au CAS ?

De mon point de vue, ça parait une bonne solution qui faciliterait le développement et l’intégration d’outils à héberger soit-même. D’ailleurs, le CAS est tout à fait capable d’interdire l’accès à certaines personnes à certains outils, ce qui permet d’ouvrir l’outil à un cercle d’utilisation plus large, jusqu’à une instance publique peut-être ?

Désolé si le pavé en a fait reculer certains ; c’était pour ouvrir la discussion. Vos avis ?

Édité par tleb

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte