L'authentification unique avec LDAP est-elle toujours recommandée aujourd'hui pour intégrer un ensemble d'outils open source?

8

Nous menons un exercice avec une institution publique pour installer différents outils open source afin qu'ils puissent expérimenter et voir ce qui leur convient le mieux.

Ainsi, nous installons:

  • un wiki (dokuwiki)
  • mediagoblin
  • gnu social
  • etherpad
  • éthercalc

et peut-être un peu plus.

Nous pensions utiliser LDAP pour harmoniser les connexions.

Mais souvent, il semble que les plugins LDAP ne sont plus maintenus et que la configuration est difficile à bien fonctionner, certains outils ont des documents LDAP insuffisants.

Est-ce encore une bonne idée aujourd'hui de le faire via LDAP? OAuth est-il peut-être un meilleur choix?

Je sais que ce n'est pas une question de code, mais ce que nous aimerions comprendre, c'est si nous devons nous en tenir à notre décision d'aller LDAP ou si nous devons envisager d'autres chemins. Merci beaucoup

transient_loop
la source

Réponses:

13

LDAP ne peut pas fournir d'authentification unique. Il y a une grande différence entre pouvoir utiliser les mêmes utilisateurs et avoir une connexion unique, ce qui signifie que vous vous connectez à tous les systèmes à la fois, avec un seul formulaire de connexion. Sinon, LDAP est parfaitement réalisable pour utiliser les mêmes informations de connexion dans tous les systèmes.

OAuth est juste un protocole de connexion et peut utiliser LDAP comme backend pour la gestion des utilisateurs.

Florin Asăvoaie
la source
2
En fait, j'étais en quelque sorte au courant de cette distinction, mais vous l'avez formulée de manière très claire et concise, merci. Je vais google sur OAuth / LDAP en tant qu'architecture de connexion unique, mais si vous avez des liens pertinents que vous souhaitez partager - très appréciés.
transient_loop
1

Dans le monde universitaire, le système CAS Apereo [anciennement Jasig] est un moyen courant d'authentification unique pour de grandes suites d'applications Web. Avec CAS, l'utilisateur saisit uniquement son mot de passe sur le serveur d'authentification - les applications individuelles valident un ticket unique au lieu de voir le mot de passe de l'utilisateur. Il s'agit d'un avantage majeur en matière de sécurité lorsqu'il s'agit d'applications développées par de nombreux groupes et fournisseurs internes, car aucune des applications n'a jamais accès aux mots de passe des utilisateurs.

Il existe de nombreuses bibliothèques client CAS disponibles pour la plupart des environnements de programmation et la prise en charge CAS intégrée devient plus courante pour les applications utilisées ou vendues aux universités. Outre le principal "Jasig CAS Server", plusieurs serveurs supplémentaires sont également disponibles, y compris le Ruby CAS Server et un module pour Drupal qui peut servir de serveur CAS pour authentifier des applications supplémentaires par rapport à la base de données Drupal.

Le serveur CAS Jasig lui-même est écrit en Java et peut être soutenu par un certain nombre de gestionnaires d'authentification , notamment:

  • Base de données
  • JAAS
  • LDAP
  • Héritage
  • OAuth 1.0 / 2.0, OpenID
  • RAYON
  • SPNEGO (Windows)
  • Approuvé (REMOTE_USER)
  • X.509 (certificat SSL client)

Le serveur CAS Jasig peut servir de source d'authentification pour l'application via un certain nombre de protocoles différents utilisés pour l'authentification unique:

  • Protocole CAS 1/2/3
  • Protocole SAML 1.1 / 2.0
  • Protocole OAuth
  • Protocole OpenId

Il peut même être utilisé comme authentification derrière un fournisseur Shibboleth ou utiliser un client Shibboleth comme back-end d'authentification.

Remarque: l'organisation Jasig fusionne avec l'organisation Apereo, donc certaines URL pourraient changer à l'avenir.

Adam Franco
la source
dans un souci de divulgation complète - il convient de mentionner que vous êtes affilié au projet en question
Journeyman Geek
C'est une bonne note. Je suis affilié au projet CAS en tant qu'utilisateur et co-mainteneur de la bibliothèque cliente PHP du système, phpCAS. J'ai déposé quelques rapports de bogues et correctifs sur le projet principal, mais je ne pense pas qu'ils aient réellement été intégrés dans le projet CAS.
Adam Franco