Zentralen Authentifizierungsserver konfigurieren
Der zentraler Authentifizierungsserver (CAS) verwaltet die Vertrauensbeziehung zwischen PTC Produkten, die am SSO-Framework teilnehmen. Der CAS fungiert als Vermittler zwischen Anwendungen. Er autorisiert Benutzeranmeldungen, sobald der Benutzer authentifiziert wurde, und ist für die Ausgabe und Verifizierung von Zugriffs-Token zuständig, die zwischen Dienstanbietern und Ressourcenservern ausgetauscht werden.
Im Folgenden finden Sie einige allgemeine Tipps, die Sie bei der Bereitstellung von eines CAS beachten sollten:
• Prüfen Sie die maximale Zeit, für die eine Benutzeranmeldesitzung gültig ist, und überlegen Sie, ob die gleichen Werte in jeder der an der SSO-Lösung beteiligten Anwendungen verwendet werden sollen.
• Bestätigen Sie, dass Systeme innerhalb einer akzeptablen Versatztoleranz für die Antwortzeit arbeiten. Wenn eine oder mehrere Systemuhren nicht mit dem CAS synchron laufen und die in den Systemen festgelegte Versatztoleranzzeit überschritten wird, löst die Konfiguration Fehler aus und verhindert die Authentifizierung von Benutzern.
SSO-fähige Produkte von PTC implementieren die folgenden zwei Authentifizierungsflüsse unter Verwendung des SSO-Frameworks und von Standardprotokollen:
• Verbundauthentifizierung
• Autorisierung – delegierte Autorisierung unter Verwendung von OAuth-Gewährungstypen
Verbundauthentifizierung
Die Verbundauthentifizierung ist der Prozess, bei dem die Anmeldeanforderung eines Benutzers validiert wird, indem sie mit den beim Identitätsanbieter gespeicherten Anmeldeinformationen verglichen wird.
In der SSO-Architektur der PTC Produkte sollte der zentrale Authentifizierungsserver (CAS) so konfiguriert werden, dass Benutzeranmeldeanforderungen an den IdP Ihres Unternehmens umgeleitet werden. Der IdP überprüft die Echtheit der Anmeldeinformationen von Benutzern und erstellt eine Bestätigung, dass der Benutzer authentifiziert wurde. Die Authentifizierung wird entweder mit SAML oder OIDC implementiert, abhängig von dem für das PTC Produkt unterstützten Protokoll (siehe SSO-Protokolle, die für PTC Produkte unterstützt werden) und der Kundenkonfiguration.
Sobald die Authentifizierung bestätigt wurde, wird an die anfordernde Anwendung die Bestätigung gesendet, dass der Benutzer erfolgreich authentifiziert wurde, und die Benutzeranmeldung wird autorisiert. Während dieser Transaktion können die Benutzeranmeldeinformationen weder vom CAS noch von der PTC Anwendung angezeigt oder verwaltet werden. Wenn der Browser zum IdP umgeleitet wird, erfolgt der Austausch von Benutzername und Passwort direkt zwischen dem Benutzer-Client-Agent (Browser) und dem IdP. Sie müssen eine separate Dienstanbieter-Verbindung (SP-Verbindung) für jedes PTC Produkt erstellen, das sich im selben Verbund befindet und sich dabei auf die Benutzerauthentifizierung über denselben CAS verlässt.
Die standardmäßigen SAML- und OIDC-Authentifizierungsflüsse werden basierend auf der SSO-Konfiguration befolgt. Die für eine bestimmte CAS-Technologie unterstützten Optionen sollten geprüft werden, bevor sie für die Verwendung in einer PTC SSO-Konfiguration ausgewählt werden.
Im folgenden Abfolgediagramm wird der Authentifizierungsfluss veranschaulicht. In diesem Beispiel fungiert ThingWorx als SP und PingFederate ist der CAS. ThingWorx verwendet das offene Standardprotokoll SAML 2.0 für den Authentifizierungsaustausch zwischen dem SP und dem IdP.
Der Authentifizierungsprozess läuft folgendermaßen ab:
1. Der Benutzer versucht, auf den Dienstanbieter zuzugreifen.
2. Der Dienstanbieter generiert eine SAML-Anforderung für den Benutzer und sendet die Anforderung an den CAS.
3. Der CAS leitet die SAML-Anforderung an den IdP um.
4. Der IDP leitet den Benutzer an eine Authentifizierungsseite um, auf der er seine Anmeldeinformationen angeben muss (z.B. Benutzername und Passwort). Sobald der Benutzer seine Anmeldeinformationen eingegeben hat, generiert der IdP eine SAML-Antwort. Wenn der Benutzer erfolgreich authentifiziert wird, enthält die SAML-Antwort eine SAML-Bestätigung mit der Autorisierung des Benutzers.
5. Der IdP leitet dann die Antwort an den CAS um.
PTC stellt für PingFederate Automatisierungsskripts für die Konfiguration von PingFederate als IdP bereit. Weitere Informationen finden Sie unter PingFederate automatisch als zentralen Authentifizierungsserver konfigurieren.
Für Drittanbieter-IdPs müssen Sie Ihren CAS im SSO-Setup konfigurieren.
Delegierte Autorisierung (OAuth)
Die delegierte Autorisierung ist ein Konzept, das es einem Dienstanbieter (SP) ermöglicht, im Namen eines Benutzers Maßnahmen zu ergreifen oder auf Ressourcen eines Ressourcenservers (RS) zuzugreifen, ohne dass der Benutzer seine Anmeldeinformationen mit dem RS teilt.
OAuth-2-Zugriffs-Token werden vom CAS angefordert, die dann in Anforderungen von Daten von Ressourcenservern verwendet werden. Ressourcenserver verlassen sich darauf, dass der Anforderer vor der Zuweisung der Zugriffs-Token vom CAS als authentifizierter Benutzer verifiziert wird. Sie müssen separate OAuth-Clients für jede PTC Anwendung erstellen, die an Szenarios mit delegierter Autorisierung teilnimmt.
PTC Produkte bieten weiteren Schutz für Ressourcen, die durch OAuth geschützt sind, indem Bereiche als zusätzliche Schutzmaßnahme konfiguriert werden. Wenn ein Dienstanbieter ein Zugriffs-Token zusammen mit seiner Anforderung für Daten vom Ressourcenserver sendet, muss für das Zugriffs-Token auch ein zugeordneter Bereich vorhanden sein, der für die Daten im Ressourcenserver registriert ist. Weitere Informationen finden Sie unter Bereiche in delegierter Autorisierung verwalten.
PTC Produkte unterstützen OAuth-Gewährungstypen für interaktive und nicht interaktive Clients. Es ist wichtig, die Client-Funktionalität zu verstehen, um den zu verwendenden geeigneten Gewährungstyp zu bestimmen.
 |
Prüfen Sie die jeweilige PTC Produktdokumentation, um die unterstützten OAuth-Gewährungstypen für Ihr Produkt zu bestätigen.
|
◦ Interaktiv: Der Benutzer authentifiziert sich beim Client, und der Client fordert Ressourcen im Namen dieses Benutzers an. Die Autorisierung für den Zugriff auf die Ressource basiert auf der Endbenutzerautorisierung.
◦ Nicht interaktiv: Auch als Machine-to-Machine-Interaktion (M2M) bezeichnet. Der Client ist eine Anwendung und muss sich bei der Anforderung eines OAuth-Tokens gegenüber dem CAS identifizieren. Die Identität im OAuth-Token ist die Rechneridentität (Client oder Dienstprinzipal) und nicht die Identität eines menschlichen Benutzers.
Im folgenden Abfolgediagramm wird der OAuth-Autorisierungscodefluss veranschaulicht. ThingWorx ist der SP, PingFederate ist der CAS und Windchill ist der RS. ThingWorx ist in einem interaktiven Client so konfiguriert, dass der Autorisierungscodefluss des offenen Standardprotokolls OAuth2 verwendet wird, um einen SP für den sicheren, zuverlässigen und effizienten Zugriff auf Ressourcen zu autorisieren, wobei die Benutzer-ID des Endbenutzers für die Autorisierung des Abrufs der Ressource verwendet wird.
Der Autorisierungsprozess läuft folgendermaßen ab:
1. Nach dem Erhalt der SAML-Antwort vom IdP sendet der CAS eine Seite zur Anforderung einer Gewährungsautorisierung, die der Benutzer genehmigen muss. Der CAS verwendet die Seite zur Anforderung einer Gewährungsautorisierung, um die Autorisierung zum Generieren eines OAuth-Codes zu erhalten.
2. Nachdem der Benutzer Zugriff gewährt hat, generiert der CAS einen OAuth-Autorisierungscode. Der CAS leitet dann die SAML-Antwort und den Autorisierungscode an den Dienstanbieter um.
3. Sobald der Dienstanbieter den OAuth-Autorisierungscode erhält, fordert er mithilfe des Autorisierungscodes ein Zugriffs-Token und ein Aktualisierungs-Token vom CAS an.
4. Der CAS validiert den Autorisierungscode und generiert ein OAuth-Zugriffs-Token und ein Aktualisierungs-Token. Der CAS sendet dann beide Token an den Dienstanbieter.
5. Der Ressourcenbesitzer (normalerweise der Benutzer) fordert Inhalt vom Dienstanbieter an, der Daten vom Ressourcenserver erfordert.
6. Der Dienstanbieter fordert mithilfe des Zugriffs-Tokens Inhalt im Namen des Ressourcenbesitzers vom Ressourcenserver an.
7. Der Ressourcenserver verifiziert das Zugriffs-Token über den CAS.
8. Der Ressourcenserver ruft dann den angeforderten Inhalt ab und sendet ihn an den Dienstanbieter.
9. Nach Erhalt des Inhalts übermittelt der Dienstanbieter ihn an den Ressourcenbesitzer.
Alternative CAS-Technologien können mit demselben Fluss konfiguriert werden. Möglicherweise müssen spezifische Konfigurationsschritte und Einstellungen berücksichtigt werden.
Bei einem nicht interaktiven Client wird der Fluss mit Client-Anmeldeinformationen verwendet, um eine Client-ID und ein Client-Verschlüsselungswort an den CAS für den Abruf eines OAuth-Tokens zu übergeben. Das OAuth-Token wird dann an den RS übergeben, um die angeforderte Ressource abzurufen. Der RS muss so konfiguriert sein, dass er den Client-Anmeldeinformationen-Gewährungstyp unterstützt, um das OAuth-Token verwalten und die Anforderung validieren zu können. Im folgenden Ablaufdiagramm wird der Fluss mit Client-Anmeldeinformationen mit einem nicht interaktiven Client dargestellt, der eine Ressource von Windchill als dem RS anfordert.
Sie können die SSO-Architektur auch als Verbund mit mehreren Dienstanbietern und mehreren Ressourcenservern konfigurieren. Die SP- und RS-Konfigurationen werden von einem einzigen CAS verwaltet. Auf diese Weise werden alle Benutzeridentitäten im Verbund gemeinsam genutzt. Im folgenden Beispiel ist Windchill Navigate der Dienstanbieter, und Windchill und SAP sind die Ressourcenserver.
