Echtes Single Sign-on (SSO)

Konzept

Single Sign-on erlaubt es, wie der Name schon sagt, einem Benutzer, sich gegenüber einer zentralen Instanz zu authentifizieren und diese Authentifizierung anschließend für den Zugriff auf mehrere Systeme zu nutzen.

Motivation

Aus Benutzersicht wird der Authentifizierungsprozess enorm vereinfacht. Man merkt sich einen Satz Zugangsdaten und durchläuft einen Login-Prozess. Das spart Zeit und mentalen Aufwand – man ist ein zufriedenerer Benutzer, ein effizienterer Mitarbeiter usw.

Aus Support-/Admin-Sicht reduziert sich ebenfalls der Zeitaufwand für vergessene Passwörter und für die Schulung von Benutzern auf mehreren Systemen. Möglicherweise sinken sogar die Hardware-Anforderungen, da doppelte Funktionalität wegfällt – darüber lässt sich allerdings streiten.

Kritikpunkte

Das offensichtliche Problem ist das „Alle Eier in einem Korb“-Problem: Gelangt Bob an Alices Zugangsdaten, hat er Zugriff auf alle Systeme, die das SSO nutzen. Dem lässt sich jedoch entgegenwirken, indem man dies durch eine stärkere Passwort-Richtlinie ausgleicht (schließlich müssen sich Ihre Benutzer nur noch ein Passwort merken) und die übliche Kombination aus Benutzername und Passwort um weitere Authentifizierungsmethoden ergänzt. Das kann durchaus so etwas wie die Zwei-Faktor-Authentifizierung sein, die Systeme wie CRYPTOCard bieten. Diese Systeme sind allerdings oft recht teuer und erfordern hohe Investitionen – das muss gegen das benötigte Sicherheitsniveau abgewogen werden.

Optionen

Es gibt eine Reihe von Standards für SSO mit einer Vielzahl von Implementierungen. Die ersten Aufzählungspunkte sind jeweils die Punkte, die Oliver angesprochen hat, anschließend ergänze ich (oder einer der anderen fleißigen Mitschreiber) gegebenenfalls weitere Anmerkungen.

Kerberos

• Nicht ganz einfach aufzusetzen
• Praktisch eigentlich nur im Intranet sinnvoll einsetzbar

LDAP/AD

• Relativ einfach aufzusetzen
• Daten lassen sich leicht zwischen Servern synchronisieren
• Man kann die ldap_*()-Funktionen von PHP nutzen
• Das Binden an den LDAP-Server entspricht der Authentifizierung gegen ihn.
• Eine Frage von Kore (glaube ich) brachte einige Probleme mit Unterschieden zwischen den Implementierungen von LDAP-Servern zur Sprache. Die Authentifizierung ist ziemlich universell, aber die fortgeschritteneren Features können sich im Verhalten unterscheiden.

NTLM

• Eine weitere Nur-Intranet-Option
• Funktioniert praktisch nur in MS-Umgebungen. Es gibt zwar Apache-Implementierungen, die sind aber wackelig.
• Für Entwickler jedoch einfach zu nutzen
• Die Windows-Domäneninformationen stehen in den Umgebungsvariablen des Servers zur Verfügung. Wenn die Benutzerinformationen vorhanden sind, hat sich der Benutzer authentifiziert.

CAS

Token-basiertes System

Entwickelt von der Yale University

Am häufigsten in akademischen Anwendungen im Einsatz

SAML

• Framework von OASIS
• Implementierung in SimpleSamlPHP
• Implementierung in PingConnect
• Implementierung in Shibboleth (ich glaube, das war eine SAML-Implementierung)
• LDAP ist ein verbreitetes Backend für viele dieser Dienste
• Vertrauen ist hier ein Thema, da diese Verfahren eher für Remote-Authentifizierung üblich sind.