Ablauf der Relying-Party-Authentifizierung

Online bearbeiten

Die Relying-Party-Authentifizierung unterstützt den Workflow für implizite Erteilung und den Workflow für Berechtigungscode.

Der Workflow für implizite Erteilung ist bei einer einmaligen Anmeldung aus dem Internet bei einer Intranet-Site nützlich. Während des Workflows für implizite Erteilung wird der /token-Endpunkt nicht benötigt und es besteht keine Direktverbindung zwischen der Relying-Party und dem OpenID-Provider (OP). Das Fehlen der Direktverbindung ist auf die Annahme zurückzuführen, dass keine Metadaten oder /userinfo konfiguriert sind.
Berechtigungscode wird gewöhnlich als sicherer betrachtet. Er bietet die einzige Möglichkeit zur Ausstellung eines Aktualisierungstokens. Sowohl das ID-Token als auch das Zugriffstoken werden als weniger gefährdet betrachtet, wenn die Relying-Party den Workflow für Berechtigungscode verwendet, weil beide Token nicht über den Browser transportiert werden.

Wird ein föderiertes SSO (single sign-on, einmalige Anmeldung) mit der OpenID Connect-Relying-Party ausgeführt, sind mehrere Schritte erforderlich. Sie sollten diese Schritte kennen, damit Sie wissen, welche Anpassungen an der angeforderten Authentifizierung möglich sind.

Der erste Schritt einer Authentifizierung ist der Start (Kickoff), der durch den Zugriff auf die folgende URL eingeleitet wird:
```
https://www.mywebseal.com/<isva junction>/sps/oidc/rp/<federation name>
/kickoff/<partner name>
```
Mit einer Junction von /isva, einem Zusammenschluss von my_federation und einem Partner von partner_company, lautet die URL beispielsweise wie folgt:
```
https://www.mywebseal.com/isva/sps/oidc/rp/my_federation/kickoff/partner_company
```
Beim erstmaligen Empfang der Startanforderung (Kickoff) werden der Zusammenschluss- und der Partnername überprüft, um sicherzustellen, dass die Anforderung an einen Zusammenschluss mit einer gültigen Konfiguration gerichtet ist. Die OIDC-OpenID-Provider-Metadaten werden jetzt abgerufen, falls sie konfiguriert sind.
Siehe Authentifizierungsmetadaten der Relying-Party.
Wurde ein Zielabfrageparameter angegeben, wird er in der Sitzung des Benutzers gespeichert.
Anschließend wird die eingehende HTTP-Anforderung zu einem STSUniversalUser (STSUU) serialisiert. Diese Struktur enthält alle eingehenden Anforderungsparameter. Alle Parameter, die der Anforderung in /authorize hinzugefügt werden müssen, werden STSUU-Kontextattributen hinzugefügt.
Ist eine erweiterte Zuordnungsregel konfiguriert, wird sie jetzt ausgeführt. Diese Aktion findet jetzt statt, so dass die Authentifizierungsanforderung an den OpenID-Provider zur Laufzeit geändert werden kann.
Siehe Erweiterte Relying-Party-Konfiguration.
Nachdem die erweiterte Zuordnungsregel aufgerufen wurde, werden state und response_type validiert. Nach der Validierung werden sie in der Benutzersitzung gespeichert.
Siehe Distributed Session Cache verwalten.
Danach wird eine Antwort an den Benutzeragenten gesendet, die den Benutzer an den OIDC-Provider weiterleitet.
Der OIDC-Provider führt seine Verarbeitungsschritte aus. Normalerweise findet eine Authentifizierung statt oder eine bereits vorhandene Sitzung wird überprüft und möglicherweise ein Aufforderung zur Zustimmung ausgegeben.
Wenn die Verarbeitung des OpenID-Providers beendet ist, wird der Benutzer über den vorab registrierten Umleitungs-URI zurück zur Relying-Party umgeleitet.
Dieser URI hat das folgende Format:
```
https://wwww.mywebseal.com/isvajct/sps/oidc/rp/<federationName>/redirect/<partnerName>
```
Mit den vorangegangenen Beispielwerten würde die URL wie folgt lauten:
```
https://wwww.mywebseal.com/isva/sps/oidc/rp/my_federation/redirect/partner_company
```
Als Nächstes wird der Umleitungs-URI der Relying-Party aufgerufen. Dieser Aufruf erfolgt auf eine der folgenden Arten:
- Wird eine GET-Anforderung vom Benutzeragenten bearbeitet, die über eine Antwort 302 vom OpenID-Provider oder über eine andere Methode kommt, und ist der Parameter state nicht durch eine Abfragezeichenfolge angegeben, sendet die Relying-Party ein selbstübertragendes Formular zurück. Das selbstübertragende Formular extrahiert den Fragmentteil der URL und sendet die Werte an die Relying-Party.
  Hinweis: Das selbstübertragendes Formular ist die Schablonenseite form_post.html. Verwenden Sie die lokale Managementschnittstelle (LMI), um diese Datei abzurufen. Rufen Sie Federation > Globale Einstellungen > Schablonendateienauf. Der Pfad zur Datei lautet C > oidc > rp > form_post.html.
- Handelt es sich um eine POST-Anforderung, werden die eingehenden Parameter validiert und die einmalige Anmeldung (SSO) wird fortgesetzt.
- Antwort 302 mit Abfragezeichenfolge. In diesem Fall verarbeitet die Relying-Party die Abfrageparameter.
  Hinweis: Der OAuth-RFC verbietet diese Aktion, wenn ein Zugriffstoken in die Umleitung eingeschlossen wird.
Sobald die Relying-Party die Umleitungsparameter vom OpenID-Provider mit einem der oben beschriebenen Verfahren empfängt, wird die Anforderung von der Relying-Party validiert. Die Validierung umfasst die Validierung des Status und die Bestätigung, dass die eingehende Anforderung alle in der Anforderung enthaltenen Antworttypen (response_types) aufweist.
Als Nächstes wird die erweiterte Zuordnungsregel aufgerufen. Dieser Aufruf kann zum Ausführen eines HTTP-Aufrufs oder zum Hinzufügen weiterer Parameter zu den /token- oder /userinfo-Anforderungen (falls konfiguriert) verwendet werden.
Falls die Anforderung ein ID-Token zurückgegeben hat, wird es validiert und entschlüsselt, wenn die Anforderung validiert wird. Die Claims und der Header dieses JWT werden zum STSUU hinzugefügt. Die Claims at_hash, nonce und c_hash des ID-Tokens werden validiert.
Falls ein Code zurückgegeben wurde, wird dieser nach der Validierung des impliziten ID-Tokens am Tokenendpunkt ausgetauscht. Danach wird die Antwort validiert und die Antwortparameter werden den STSUU-Kontextattributen hinzugefügt.
Das vom Tokenendpunkt zurückgegebene ID-Token wird anschließend validiert und entschlüsselt und seine Claims werden überprüft.
Ist der Zugriff auf Benutzerinformationen für die Relying-Party konfiguriert und besitzt die Relying-Party ein Zugriffstoken, stellt sie mit dem Zugriffstoken eine Anforderung an /userinfo. Die Antwort wird in die STSUU-Attributliste aufgenommen. Der zurückgegebene Claim sub wird mit dem Claim sub im ID-Token abgeglichen.
Der STSUU wird jetzt an den letzten Identitätszuordnungsschritt übergeben, in dem der STSUU zu einem Berechtigungsnachweis verarbeitet wird. Dieser Schritt wird über einen HTTP-Aufruf oder eine JavaScript-Zuordnungsregel ausgeführt, je nach Konfiguration.
Siehe Relying Party Identity Mapping.
Wenn Sie einen Benutzer authentifizieren, der nicht in der Security Verify Access -Registry vorhanden ist, muss die Point of Contact-Konfiguration aktualisiert werden, um diese Authentifizierung widerzuspiegeln.
Siehe Point of Contact-Profile für Föderation.