Auf SAML 2.0 basierende föderierte Authentifizierung
Unica Platform implementiert einen auf SAML 2.0 basierenden Identitätsprovider (IdP), der eine Single Sign-on-Föderation zwischen Unica-Produkten oder zwischen Unica-Produkten und Anwendungen anderer Anbieter aktiviert.
Eine Föderation ist eine Gruppe von IdPs und Anwendungen, die in einer vertrauenswürdigen Umgebung zusammenarbeiten und Services für einander mit SAML 2.0 (Security Assertion Markup Language) basierend auf Standards bereitstellen.
Anwendungen, die Mitglieder einer Föderation sind, werden als Service Provider (SPs) bezeichnet. Der IdP-Server und die SPs können vor Ort oder in einer Cloud gehostet werden.
Eine SAML 2.0-Föderation unterstützt verschiedene Authentifizierungsmechanismen für Single Sign-on. Ein Benutzer kann beispielsweise in einem SP authentifiziert werden, der den Authentifizierungsmechanismus dieser Anwendung verwendet (z. B. intern, OAuth, OpenId, SAML, Kerberos). Anschließend kann der Benutzer auf andere SPs mit föderiertem Single Sign-on zugreifen, wenn die Anwendungen Teil derselben Föderation sind und der Benutzer entsprechend zugeordnet ist.
Der IdP-Server erzeugt, validiert oder löscht Token basierend auf Benutzerzuordnungen. Datenzugriffsobjekte werden für die unterstützen Datenbanktypen implementiert und in den IdP-Server eingeschlossen.
Ein Administrator ordnet Benutzer-IDs zwischen SPs zu, um Single Sign-on-Zugriff für zugeordnete Benutzer bereitzustellen. Beispiel: Angenommen, SP_A und SP_B sind Mitglieder derselben Föderation. Benutzer1 ist ein Konto in SP_A und Benutzer2 ist ein Konto in SP_B. Das Konto von Benutzer1 wird in der Föderation dem Konto von Benutzer2 zugeordnet. Wenn sich ein Benutzer mit den Berechtigungsnachweisen von Benutzer1 bei SP_A anmeldet, verfügt dieser Benutzer über Single Sign-on-Zugriff auf SP_B. Und wenn sich ein Benutzer bei SP_B mit den Berechtigungsnachweisen von Benutzer2 anmeldet, verfügt dieser Benutzer über Single Sign-on-Zugriff auf SP_A.
Diagramm
Im folgenden Diagramm ist diese Föderation dargestellt.

Komponenten der HCL Implementierung
Die Implementierung des auf SAML 2.0 basierenden föderierten Single Sign-on umfasst die folgenden Komponenten.
Diese Komponenten befinden sich im Verzeichnis tools/lib unter Ihrer Unica Platform-Installation.
- Ein auf SAML 2.0 basierender IdP-Server, der als WAR-Datei bereitgestellt wird:
idp-server.war - Eine Clientfassade:
idp-client.jarDie IdP-Clientfassade ist eine Java™-Implementierung mit einer API, die mit Sicherheitstoken arbeitet. Sie wird als JAR-Datei bereitgestellt. Die Javadoc™ Dokumentation für die API ist in Unica Platform Javadoc enthalten.
Die IdP-Clientfassade aktiviert Java-SPs für die schnelle Integration mit dem IdP-Server und um Teil der Föderation zu werden.
Unterstützte Anwendungsfälle
Durch die aktuelle Implementierung können SPs mit Sicherheitstoken arbeiten, um die Single-Sign-on-Authentifizierung zwischen den SPs zu erreichen.
Generieren eines neuen SAML-Token
Die Implementierung kann ein neues SAML-Token für einen Benutzer generieren, der eine Single Sign-on-Authentifizierungsanforderung initiiert. Dieser Benutzer muss dem IdP-Server zugeordnet werden. Der IdP-Server erzeugt basierend auf den Berechtigungsnachweisen der vertrauenswürdigen Partei und der Benutzerzuordnung ein neues Sicherheitstoken und setzt es mit einer SAML 2.0-Zusicherung ab.
Beispiel: Wenn Benutzer1 von SP_A zu Benutzer2 mit SP_B auf dem IdP-Server zugeordnet ist und Benutzer1 versucht, auf SP_B-Ressourcen zuzugreifen, generiert der IdP-Server ein Sicherheitstoken für Benutzer1 als vertrauenswürdige Partei.
Validieren eines vorhandenen SAML-Token
Die Implementierung kann ein vorhandenes SAML-Token validieren, das durch einen SP dargestellt wird und das die Zugriffsanforderung von einem Benutzer von einem anderen SP empfängt. Der SP validiert zunächst das Sicherheitstoken und die Clientzuordnung mit dem IdP-Server, um den zugeordneten Benutzer in der eigenen Domäne zu identifizieren.
Beispiel: Wenn SP_A versucht, im Namen von Benutzer1 auf SP_B-Ressourcen zuzugreifen, und das IdP-Sicherheitstoken darstellt, übergibt SP_B dieses Token an den IdP-Server. Wenn das Token gültig und Benutzer1 zu einem SP_B-Benutzer zugeordnet ist, löst der IdP-Server den SP_B-Benutzer in der SP_B-Domäne auf und gibt die Zusicherung zurück.
Löschen eines vorhandenen SAML-Token
Die Implementierung kann ein vorhandenes SAML-Token für einen SP-Benutzer löschen, wenn sich ein Benutzer beim System abmeldet oder das Zeitlimit der Sitzung aufgrund von Inaktivität überschritten wird. Der IdP-Server löscht das Token basierend auf den Berechtigungsnachweisen der vertrauenswürdigen Partei und der Benutzerzuordnung und setzt die Zeitmarke für den letzten Zugriff zurück, wenn die Abmeldeanforderung empfangen wird. Die Zuordnung des Benutzers wird dadurch NICHT gelöscht.
Einschränkungen
Die aktuelle Implementierung unterstützt die folgenden Anwendungsfälle nicht.
- Erzeugen einer neuen Benutzerzuordnung zwischen SP-Benutzern über eine Benutzerschnittstelle oder API
- Aktualisieren einer vorhandenen Benutzerzuordnung zwischen SP-Benutzern über eine Benutzerschnittstelle oder API
- Löschen einer vorhandenen Benutzerzuordnung zwischen SP-Benutzern über eine Benutzerschnittstelle oder API
Föderierte Authentifizierung und Partitionen
Wenn Ihre Unica-Umgebung über mehrere Partitionen verfügt, können Sie separate, auf SAML 2.0 basierende föderierte Authentifizierungen pro Partition einrichten. Um dies zu implementieren, müssen Sie auf der Seite neue Eigenschaften in der Kategorie Unica Platform | Sicherheit | Föderierte Authentifizierung | Partitionen | Partition[n] für jede Partition erzeugen.