Wird Single Sign On mit LDAP noch heute empfohlen, um eine Reihe von Open Source-Tools zu integrieren?

Wir führen eine Übung mit einer öffentlichen Einrichtung durch, um verschiedene Open-Source-Tools zu installieren, mit denen sie experimentieren und herausfinden können, was am besten zu ihnen passt.

Also installieren wir:

• ein Wiki (Dokuwiki)
• Mediagoblin
• gnu social
• Etherpad
• Äthercalc

und möglicherweise noch mehr.

Wir haben darüber nachgedacht, LDAP zu verwenden, um die Anmeldungen zu harmonisieren.

Oft scheint es jedoch so, als ob die LDAP-Plugins nicht mehr gewartet werden und die Konfiguration schwierig zu funktionieren ist. Einige Tools verfügen über unzureichende LDAP-Dokumente.

Ist es heute noch eine gute Idee, dies über LDAP zu tun? Ist OAuth vielleicht eine bessere Wahl?

Ich weiß, dass dies keine Codefrage ist, aber wir möchten verstehen, ob wir an unserer Entscheidung für LDAP festhalten oder andere Wege in Betracht ziehen sollten. Danke vielmals

LDAP kann Single Sign On nicht bereitstellen. Es gibt einen großen Unterschied zwischen der Verwendung derselben Benutzer und der einmaligen Anmeldung. Dies bedeutet, dass Sie sich mit einem einzigen Anmeldeformular gleichzeitig bei allen Systemen anmelden. Andernfalls ist LDAP durchaus möglich, um in allen Systemen dieselben Anmeldeinformationen zu verwenden.

OAuth ist nur ein Protokoll für die Anmeldung und kann LDAP als Backend für die Benutzerverwaltung verwenden.

In der Universitätswelt ist das Apereo [ehemals Jasig] CAS- System eine übliche Methode, um Single Sign On für große Suiten von Webanwendungen durchzuführen . Bei CAS gibt der Benutzer sein Kennwort immer nur auf dem Authentifizierungsserver ein. Einzelne Anwendungen validieren ein Einmal-Ticket, anstatt das Kennwort des Benutzers anzuzeigen. Dies ist ein großer Sicherheitsgewinn bei Anwendungen, die von vielen internen Gruppen und Anbietern entwickelt wurden, da keine der Anwendungen jemals Zugriff auf die Kennwörter der Benutzer hat.

Für die meisten Programmierumgebungen stehen zahlreiche CAS-Client-Bibliotheken zur Verfügung, und die integrierte CAS-Unterstützung wird für Anwendungen, die an Universitäten verwendet oder verkauft werden, immer häufiger. Neben dem Hauptserver "Jasig CAS Server" stehen mehrere zusätzliche Server zur Verfügung, darunter der Ruby CAS Server und ein Modul für Drupal , das als CAS-Server für die Authentifizierung zusätzlicher Anwendungen gegenüber der Drupal-Datenbank fungieren kann.

Der Jasig CAS Server selbst ist in Java geschrieben und kann von einer beliebigen Anzahl von Authentifizierungshandlern unterstützt werden , darunter:

• Datenbank
• JAAS
• LDAP
• Erbe
• OAuth 1.0 / 2.0, OpenID
• RADIUS
• SPNEGO (Windows)
• Vertrauenswürdig (REMOTE_USER)
• X.509 (Client-SSL-Zertifikat)

Der Jasig CAS-Server kann über eine Reihe verschiedener Protokolle, die für Single Sign On verwendet werden, als Authentifizierungsquelle für die Anwendung dienen:

• CAS-Protokoll 1/2/3
• SAML-Protokoll 1.1 / 2.0
• OAuth-Protokoll
• OpenId-Protokoll

Es kann sogar als Authentifizierung hinter einem Shibboleth-Anbieter oder als Shibboleth-Client als Authentifizierungs-Backend verwendet werden.

Hinweis: Die Jasig-Organisation wird mit der Apereo-Organisation zusammengeführt, sodass sich einige URLs in Zukunft möglicherweise ändern.