X.509 als Basis für SSO

Eine der interessantesten Optionen für den Aufbau von Single-Sign-On- Umgebungen ist die Verwendung von X.509v3-Zertifikaten in Verbindung mit SSLv3. Damit kann die Authentifizierung transparent im Hintergrund erfolgen. Die wichtigsten Aspekte in diesem Zusammenhang werden in diesem Artikel erläutert.

Der Standard X.509v3 bildet die Basis für digitale Zertifikate. Diese Zertifikate identifizieren eine Person oder einen Dienst bzw. einen Server. Der wichtigste Einsatzbereich ist die Authentifizierung von Servern bei SSL/TLS (Secure Sockets Layer/Transport Layer Security). SSLv3 unterstützt aber auch die Client-Authentifizierung. Dabei handelt es sich um eine gegenseitige Authentifizierung, in deren Rahmen beim Verbindungsaufbau sowohl der Server – wie immer bei SSL – als auch der Client authentifiziert werden.

Die Voraussetzung beim Client SSLv3 wird bei Zugriffen über das Internet genutzt. Der häufigste Einsatzbereich ist HTTP. Das Verfahren wird aber auch bei IMAP, POP3 und LDAP unterstützt.

Damit ein Client damit arbeiten kann, muss er SSLv3 unterstützen. Das ist aber bei allen heute üblichen Systemen der Fall. Darüber hinaus muss auf dem Client ein digitales Zertifikat vorhanden sein. Dieses kann lokal gespeichert sein oder von einem externen Speicher – in der Regel einer Smartcard – geladen werden. Der einfachste Ansatz ist die Verwaltung solcher Zertifikate innerhalb von Werkzeugen wie dem Internet Explorer (Bild 1). Die lokale Speicherung ist allerdings nur begrenzt sicher, da die Sicherheit der Zertifikate unmittelbar von der Sicherheit des Betriebssystems abhängt.

Bild 1: Digitale Zertifikate können direkt im Internet Explorer gespeichert und verwaltet werden.
Bild 1: Digitale Zertifikate können direkt im Internet Explorer gespeichert und verwaltet werden.

Da die Anwendungen auf Zertifikatsanforderungen automatisch reagieren, muss der Benutzer nur den Zertifikatsspeicher entsperren. Wenn die Zertifikate im Internet Explorer gespeichert sind, geschieht das mit der Authentifizierung bei Windows. Falls mit Smartcards gearbeitet wird, muss typischerweise eine PIN für diese Smartcard eingegeben werden.

Da die Authentifizierung im Hintergrund erfolgt, muss man sich auch über Themen wie die Lebensdauer von Cookies oder ein Web-SSO über mehrere Server hinweg keine Gedanken machen – ob das Zertifikat nun öfter oder seltener präsentiert wird, bleibt für den Benutzer transparent.

Die Verarbeitung beim Server

Bei den verschiedenen Internet-Protokollen mit Unterstützung für SSLv3 wird die Unterstützung für Client-Zertifikate im Serverdokument bei Ports…/Internet Ports… und dort jeweils den spezifischen Einstellungen für die Protokolle aktiviert (Bild 2).

Bild 2: Die Konfiguration der Client-Authentifizierung im Konfigurationsdokument eines Domino-Servers.
Bild 2: Die Konfiguration der Client-Authentifizierung im Konfigurationsdokument eines Domino-Servers.

Dort findet sich jeweils die Option Client certificate bei Authentication options. Die anderen Authentifizierungsverfahren können auch weiterhin verwendet werden. Zusätzlich muss bei den Einstellungen definiert werden, ob auch abgelaufene SSL-Zertifikate akzeptiert werden. In der Regel sollten solche Zertifikate nicht zugelassen werden, da sie ein Sicherheitsrisiko darstellen.

Wichtig ist, dass beim Server die CA, von der die Client-Zertifikate ausgestellt werden, als Trusted Root konfiguriert ist. Diese Einstellung wird bei der Konfiguration der CA vorgenommen. Die wichtigsten externen CAs sind bereits als Trusted Roots (vertrauenswürdige Stammzertifizierungsstellen) konfiguriert.

Wichtig ist, dass der Benutzername in den Zertifikaten mit dem Benutzernamen in den Personendokumenten des Domino Directory übereinstimmt. Dieses Attribut wird verwendet, um Zertifikate zu Benutzern zuzuordnen.

Die Verwendung von Client-Zertifikaten für die Authentifizierung ist im Prinzip sehr einfach – wenn man erst einmal die entsprechende PKI (Public Key Infrastructure) für die Erstellung und Verwaltung digitaler Zertifikate und gegebenenfalls das Management von Smartcards hat. Da die Technologie auf sehr breiter Basis unterstützt wird, lassen sich aber auch komplexe Integrationsanforderungen effizient darüber abdecken, ohne im Backend aufwändige Integrationsarbeit leisten zu müssen.