Zentralen Authentifizierungsserver konfigurieren – PingFederate
PTC unterstützt PingFederate als zentralen Authentifizierungsserver (Central Auth Server, CAS). Der 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.
PTC Produkte implementieren die folgenden Elemente im SSO-Framework:
1. Verwenden Sie SAML-Bestätigungen, um Benutzer beim IdP zu authentifizieren.
2. Nachdem der Benutzer authentifiziert wurde, zeigt PingFederate dem Benutzer eine Seite für die Berechtigungsgewährung an. Auf dieser Seite wird der Benutzer gefragt, ob seine Daten vom Ressourcenserver mit der von ihm verwendeten Anwendung geteilt werden sollen.
Wenn Sie mit PingFederate arbeiten, sollten Sie die PingFederate-Dokumentation als Referenz nutzen. Im Folgenden finden Sie einige allgemeine Tipps, die Sie bei der Bereitstellung von PingFederate 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.
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 werden Benutzeranmeldungen von PingFederate nicht direkt authentifiziert. Stattdessen sollte PingFederate so konfiguriert werden, dass Benutzeranmeldeanforderungen an den IdP Ihres Unternehmens umgeleitet werden. Der IdP überprüft die Echtheit der Anmeldeinformationen von Benutzern und sendet eine Bestätigung an PingFederate, dass der Benutzer authentifiziert wurde. Anschließend sendet PingFederate eine Bestätigung an die anfordernde Anwendung, dass der Benutzer authentifiziert wurde, und autorisiert die Benutzeranmeldung. Während dieser Transaktion werden die Anmeldeinformationen des Benutzers nicht von PingFederate verarbeitet. 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 für jedes PTC Produkt erstellen, das die Benutzerauthentifizierung über PingFederate leitet.
Im folgenden Beispiel ist ThingWorx der Dienstanbieter und PingFederate der CAS. ThingWorx verwendet das offene Standardprotokoll SAML 2.0 für den Authentifizierungsaustausch zwischen dem Dienstanbieter und dem Identitätsanbieter.
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. Die IdP leitet dann die Antwort an den CAS um.
PTC stellt Automatisierungsskripts für die PingFederate-Konfiguration mit PingFederate als IdP bereit. Weitere Informationen finden Sie unter PingFederate automatisch als zentralen Authentifizierungsserver konfigurieren.
Für Drittanbieter-IdPs müssen Sie PingFederate im SSO-Setup konfigurieren. Weitere Informationen finden Sie unter Authentifizierung für Drittanbieter-IdPs manuell konfigurieren.
Delegierte Autorisierung
Die delegierte Autorisierung ist ein Konzept, das es einem Dienstanbieter 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.
PingFederate generiert OAuth 2-Zugriffs-Token, die PTC Produkte in Anforderungen für Daten von Ressourcenservern einschließen. Ressourcenserver verlassen sich bei der Überprüfung der Echtheit der Zugriffs-Token auf den CAS. 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.
Im folgenden Beispiel ist ThingWorx der Dienstanbieter, PingFederate der CAS und Windchill der Ressourcenserver. ThingWorx verwendet das offene Standardprotokoll OAuth2, um einen Dienstanbieter zu autorisieren, sodass er auf sichere, zuverlässige und effiziente Weise auf Ressourcen zugreifen kann.
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.
Sie können auch SSO-Architektur mit mehreren Ressourcenservern implementieren. Im Beispiel ist ThingWorx Navigate der Dienstanbieter, und Windchill und SAP sind die Ressourcenserver.
