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

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

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.

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.