SICHERHEIT


Authentifizierung mittels föderierter Identität über Security Assertion Markup Language (SAML) konfigurieren
Die föderierte Identität ist eine Möglichkeit zur Realisierung einmaliger Anmeldungen. Sie erhöht den Komfort für den Benutzer und senkt die Verwaltungskosten. In Domino und Notes verwendet die föderierte Identität für die Benutzerauthentifizierung den SAML-Standard (Security Assertion Markup Language) von OASIS.

Warum und wann dieser Vorgang ausgeführt wird

Bei der SAML-Authentifizierung genügt es, wenn sich ein Benutzer einmal bei einem bestimmten Identitäts-Provider (IdP) authentifiziert. Anschließend kann der Benutzer auf jeden Server zugreifen, der Partner des IdPs ist. Die SAML-basierte Authentifizierung kann sowohl von Notes-Client- als auch von Web-Client-Benutzern genutzt werden. Die Authentifizierung ist von signierten XML-Identitäts-Assertions abhängig. Die Vorteile für den Benutzer sind eine transparente Authentifizierung und einmalige Anmeldung. Die Authentifizierung erfolgt dabei einmalig für mehrere Domino-Web-Server und Anwendungen sowie für Anwendungen eines anderen Herstellers, für die ebenfalls eine Partnerschaft mit dem IdP besteht. Der IdP bestimmt die Methode für die einmalige Authentifizierung. Der Benutzer kann zur Eingabe eines Kennworts aufgefordert werden, es kann jedoch auch eine Authentifizierungsmethode ohne Kennwort eingesetzt werden, wie die integrierte Windows™-Authentifizierung (SPNEGO/Kerberos) bei Benutzern in einem Intranet.

Es gibt drei Fälle, in denen eine Organisation die SAML-Authentifizierung verwenden kann. Dabei werden u. U. alle Konfigurationen oder auch nur eine Konfiguration benötigt.


Der Administrator kann einen Domino-Server für die SAML-Authentifizierung einrichten, indem er ihn zum Partner eines vor Ort verfügbaren Servers für die föderierte Identität macht. Dies kann ein IBM® Tivoli Federated Identity Manager (TFIM) in Kombination mit einem IBM Tivoli Access Manager-(TAM-)Authentifizierungsservers sein. Der TAM/TFIM-Server wird zum Identitäts-Provider (IdP) und der Domino-Server wird bei IdP als Provider des SAML-Authentifizierungsservice registriert.

Domino unterstützt SAML 1.1 und SAML 2.0. Welche SAML-Version Sie verwenden, hängt teilweise vom ausgewählten Identitäts-Provider ab. SAML 2.0 wird empfohlen, es sei denn, Ihre Organisation muss aus einem bestimmten Grund SAML 1.1 verwenden. SAML 1.1 wird u. U. für die einmalige Anmeldung bei bestimmten Anwendungen benötigt.

Je nachdem, welche SAML-Ebene für die beteiligten Anwendungen benötigt wird, kommen die folgenden Identitäts-Providers, die SAML unterstützen, als die Föderation infrage, deren Partner Domino ist:

Tabelle 1. Von Identitäts-Providern unterstützte SAML-Versionen
Identitäts-Provider (IdP)SAML-Version
IBM Tivoli Access Manager/Tivoli Federated Identity Manager (TAM/TFIM)SAML 1.1 oder SAML 2.0
Microsoft™ Active Directory Federation Services (ADFS)erfordert SAML 2.0

Wichtig: Die SAML-Authentifizierung schließt Zeitmarken ein. Stellen Sie sicher, dass die Systemzeiten des SAML-IdP-Computers und des Computers des Domino-SAML-Service-Providers synchronisiert sind, damit beide dieselbe aktuelle Uhrzeit aufweisen. Weisen die Systemzeiten keine ausreichende Synchronität auf, wird eine SAML-Assertion u. U. zurückgewiesen, weil sie anscheinend eine ungültige Uhrzeit aufweist. Dies ist insbesondere dann problematisch, wenn der IdP-Computer eine spätere Systemzeit aufweist als der Domino-Server, sodass Domino eine Assertion zurückweist, deren Zeitangabe anscheinend in der Zukunft liegt.

Informationen zu NOTES.INI-Einstellungen zur Vermeidung von Zeitabweichungen finden Sie im Notes- und Domino-Wiki und in den IBM Support-Technotes.

Kompatibilität

In der folgenden Tabelle sind Client-Konfigurationen aufgeführt, mit denen SAML nicht oder nur teilweise kompatibel ist.

Tabelle 2. Mit SAML inkompatible Client-Konfigurationen
In Ihrer Organisation verwendetSAML wird nicht empfohlen, weil ...
Smartcard-geschützte IDBenutzer-IDs für die föderierte Anmeldung können keine Smartcard-geschützten IDs sein, weil die für die föderierte Notes-Anmeldung benötigte ID-Vault nicht mit einer Smartcard-geschützten ID verwendet werden kann.
Notes-Roaming-Benutzer, dessen ID-Datei auf dem Server in einem persönlichen Roaming-Adressbuch gespeichert istBenutzer der föderierten Anmeldung können keine Notes-Roaming-Benutzer sein, deren IDs in einem persönlichen Roaming-Adressbuch gespeichert sind, weil die für die föderierte Notes-Anmeldung benötigte ID-Vault nicht mit Notes-IDs verwendet werden kann, die in einem persönlichen Roaming-Adressbuch gespeichert sind.
Notes auf einer USB-EinheitDie föderierte Anmeldung kann nicht mit Notes auf einer USB-Einsatz verwendet werden, weil die für die föderierte Notes-Anmeldung benötigte ID-Vault nicht mit Notes auf einer USB-Einheit verwendet werden kann.
Notes-Benutzer-IDs mit mehreren KennwörternBenutzer-IDs für die föderierte Anmeldung können keine Notes-Benutzer-IDs mit mehreren Kennwörtern sein, weil die für die föderierte Notes-Anmeldung erforderliche ID-Vault nicht mit IDs, die mehrere Kennwörter aufweisen, verwendet werden kann.
Serverbasierte Kennwortüberprüfung für Notes-BenutzerDeaktivieren Sie diese Funktion auf Serverplattformen, wenn Sie alle Notes-Benutzer für eine föderierte Notes-Anmeldung konfigurieren. Die Kennwortüberprüfung kann für Benutzer ohne föderierte Anmeldung erzwungen werden, bei Benutzern mit föderierter Anmeldung ist dies jedoch nicht möglich.

Prozedur

Führen Sie die folgenden Aufgaben aus.