SSO unter Immersiv

• Nicht definierter Typ

Configuration

Diese Dokumentation beschreibt, wie man RestFrontage SSO konfiguriert, Immersive Konten anhängt sowie SAML 2.0 und OpenID-Journeys. Sie ist für immersive Administratoren, Identity Federation Manager und Integratoren von Client-Anwendungen gedacht.

1. Verständnis von SSO im Immersiven

Die Single Sign-On, oder SSO, ermöglicht es einem Benutzer, sich bei einem externen Identitätsanbieter zu authentifizieren und dann auf eine immersive Anwendung zuzugreifen. Der Identitätsanbieter, genannt IdP, verwaltet die Anmeldung und kann eigene Anforderungen durchsetzen, wie zum Beispiel die Multi-Faktor-Authentifizierung.

RestFrontage findet dann ein immersives Konto aus der externen Identität, überprüft den Status dieses Kontos und stellt ein immersives Authentifizierungstoken aus. Die von der Anwendung verwendeten Rechte bleiben weiterhin die des Kontos, seiner Gruppen und seiner Berechtigungen in Immersive.

1.1 Die drei Elemente zur Unterscheidung

Element	Rolle
Externe Identität	Identifiziert die Person mit dem IdP. Sie muss mit einem Immersiv-Konto abgestimmt werden können.
Immersives Konto	Trägt den Kontostatus und seine Rechte an den Objekten und Funktionen der Plattform.
Immersive Token	Wird von RestFrontage nach der Authentifizierung zurückgegeben und für nachfolgende Austausche mit der API verwendet. Die Dauer der Frontage hängt von der Konfiguration der Anwendung ab.

Das IdP-Zugriffstoken, die SAML-Antwort und das immersive Token sind verschiedene Elemente. Eine erfolgreiche Authentifizierung am IdP reicht nicht aus, um Rechte in Immersive zu gewähren.

flowchart TD
    A["Authentification auprès du fournisseur d’identité"] --> B["Identité externe"]
    B --> C{"Compte Immersive correspondant ?"}
    C -->|"Non"| X["Connexion refusée"]
    C -->|"Oui"| D{"Compte activé, non expiré et non verrouillé ?"}
    D -->|"Non"| X
    D -->|"Oui"| E["Émission d’un jeton Immersive"]
    E --> F["Accès selon les droits du compte et de ses groupes"]

1.2 Die beiden verfügbaren Kurse

RestFrontage stellt zwei externe Authentifizierungspfade bereit: SAML und OpenID. Beide ermöglichen es Ihnen, ein bestehendes Immersivers-Konto zu finden, dessen Status zu überprüfen und ein Immersives Token auszustellen. Die Rechte bleiben bei dem Konto und seinen Gruppen.

Diese Reisen unterscheiden sich darin, wie der Klient und RestFrontage mit dem Identitätsanbieter interagieren:

Verbindungsphase	Mit SAML	Mit OpenID
Externe Authentifizierung starten	Der Client fragt RestFrontage nach einer SAML-URL und öffnet dann die Anmeldeseite des Identitätsanbieters.	Der Client authentifiziert sich beim Identitätsanbieter, um ein externes Zugriffstoken zu erhalten.
Senden Sie das Ergebnis an RestFrontage	Der Browser übermittelt eine XML-SAML-Antwort an RestFrontage.	Der Client übergibt den externen Zugriffstoken an RestFrontage.
Identifizieren Sie den externen Account	RestFrontage liest das Kontoattribut in der SAML-Antwort.	RestFrontage ruft tokeninfo und dann userinfo auf und liest die Login-Eigenschaft.
Vollständige immersive Verbindung	Der Client tauscht die SAML-Anfrage-ID nach der Kontoverifizierung gegen ein Immersive Token ein.	RestFrontage gibt nach Anrufen beim Identitätsanbieter und der Kontoverifizierung ein Immersive Token aus.

Wenn der Identitätsanbieter und die Client-Anwendung mit den unterstützten Pfaden kompatibel sind, erfolgt die Verbindung durch Konfiguration des RestFrontage, des Identitätsanbieters und des Clients und anschließend durch Anbindung der immersiveren Konten. Dann ist keine spezifische Verbindungsentwicklung erforderlich. Allerdings kann eine Anpassung erforderlich sein, wenn die erwarteten Austausche oder die Sicherheitsanforderungen der Implementierung nicht von der Implementierung abgedeckt werden.

1.2.1 Korrespondenz mit dem Immerse-Account

RestFrontage verwendet den vom Identitätsanbieter erhaltenen Kontonamen, um nach einem immersiven Nutzer zu suchen. Dieser Wert muss mit dem Name des externen Heimkontos, rief AssociatedExternalUserAccountName in der Vorlage.

Mit SAML, stammt der Wert von einem Attribut in der XML-Antwort, die vom Identitätsanbieter gesendet wird. RestFrontage sucht zunächst nach dem benannten Attribut cn. Wenn es fehlt, sucht es nach dem benannten Attribut http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name.

Der Identitätsanbieter-Administrator konfiguriert die übergebenen Attribute für die Immersive App. Der Name cn hier bezeichnet ein Attribut der SAML-Antwort: RestFrontage sucht diesen Wert nicht direkt in einem Verzeichnis. Das SAML-Feld NameID wird nicht verwendet, um das Immersive Konto zu finden.

Mit OpenID, der Wert stammt aus der Eigenschaft login des vom Dienst zurückgegebenen JSON-Dokuments userinfo des Identitätsanbieters.

Zum Beispiel, wenn das Immersive Konto hat agent.demo als externer Heimkontoname, das behaltene SAML-Attribut oder die OpenID-Eigenschaft login muss enthalten sein agent.demo.

1.2.2 In RestFrontage definierte Routen

Die folgenden Pfade sind in der Anwendung definiert. Sie beziehen sich auf die Basisadresse, unter der RestFrontage veröffentlicht wird.

Funktion	Methode und relativer Weg
Erhalten Sie die SAML-Anmelde-URL	HOL DICH /api/Saml/GetSamlUrl
Erhalten Sie die Antwort auf die SAML-Anmeldung	POST /api/Saml/Login
Hol dir das Immersive Token nach der Rückgabe von SAML	POST /api/Saml/Authenticate
Holen Sie sich die SAML-Abmelde-URL	HOL DICH /api/Saml/GetSamlLogoutUrl
Feedback zum SAML-Logout erhalten	HOLEN oder POSTEN /api/Saml/Logout
Verifizieren Sie das externe Token mit OpenID-Diensten	HOL DICH /api/OpenID/CheckToken
Holen Sie sich den Immersive Token vom externen Token	POST /api/OpenID/Authenticate

Der OpenID-Controller definiert keine Route, um die Verbindung zum Identitätsanbieter zu öffnen oder ein föderiertes Ausloggen durchzuführen. Diese Operationen hängen von der Integration des Clients mit dem Identitätsanbieter ab.

Die SAML-Logout-Rückgabe widerruft die Immersive Tokens in der untersuchten Methode nicht ausdrücklich. Das Abschließen der Sitzung beim Identitätsanbieter und das Ende des Immersiv-Zugriffs sollten daher separat überprüft werden.

1.2.3 Serverkonfigurationsabschnitte

Saml und OpenID sind Abschnitte der RestFrontage-Anwendungskonfiguration, die an der Wurzel der Rest Frontage-Konfigurationsdatei platziert sind appsettings.json. Ihre Werte können auch von den Umgebungsvariablen des Hostings bereitgestellt werden.

• Der Abschnitt Saml enthält die Adressen des Identitätsanbieters, die Immersive Service ID und die öffentlichen URLs, die zu RestFrontage zurückkehren.
• Der Abschnitt OpenID enthält die Basisadresse der Tokeninfo- und Benutzerinfo-Dienste sowie die von RestFrontage erwartete Anwendungskennung.

SAML-Einstellungen LoginUrl und LogoutUrl Geben Sie die öffentlichen URLs an, die zu den Routen führen /api/Saml/Login und /api/Saml/Logout. Sie schaffen keine neuen Straßen.

1.2.4 SAML-Reise

Der Identitätsanbieter leitet eine SAML-Antwort durch den Browser weiter. Der Client tauscht dann die Identifikatorin für diese Verbindung gegen ein Immersiv-Token aus. Das Schema zeigt die Reise, wenn alle Schritte erfolgreich sind.

sequenceDiagram
    participant C as Client et navigateur
    participant R as RestFrontage
    participant I as Fournisseur d’identité

    C->>R: Demander l’URL de connexion SAML
    R-->>C: URL de connexion
    C->>I: Ouvrir la connexion et s’authentifier
    I-->>C: Réponse SAML
    C->>R: Transmettre la réponse SAML
    R->>R: Retrouver le compte externe et mémoriser la demande
    R-->>C: Retour de connexion
    C->>R: Envoyer l’identifiant de demande chiffré
    R->>R: Retrouver la demande et vérifier l’état du compte
    R-->>C: Jeton Immersive et utilisateur

1.2.5 OpenID-Reise

Der Client erhält zunächst ein externes Zugriffstoken. RestFrontage fragt dann die Dienste des Identitätsanbieters ab, um das immersive Konto zu finden. Das Diagramm zeigt den spezifischen Weg für diese Veröffentlichung, wenn alle Schritte erfolgreich sind.

sequenceDiagram
    participant C as Client Immersive
    participant R as RestFrontage
    participant I as Fournisseur d’identité

    C->>I: S’authentifier et obtenir un jeton d’accès
    I-->>C: Jeton d’accès externe
    C->>R: Envoyer le jeton externe chiffré
    R->>I: Appeler tokeninfo
    I-->>R: client_id, access_token et realm
    R->>R: Comparer client_id avec FidAppId
    R->>I: Appeler userinfo avec le jeton retourné
    I-->>R: Identité contenant login
    R->>R: Retrouver le compte Immersive à partir de login
    R->>R: Vérifier l’état du compte
    R-->>C: Jeton Immersive et utilisateur

2. Vorbereitung der Verbindung

2.1 Informationen werden gesammelt

Informationen	Zu erhalten aus
RestFrontage HTTPS öffentliche URL, einschließlich beliebiger Pfadpräfixe	Immersives Operator-Team.
Client-Anwendungs-URL und erwarteter Anmeldepfad	Immersives Operator-Team.
Zielumgebung und erlaubter Netzwerkzugang	Betriebs- und Netzwerkteams.
Stabile externe Kennung des Pilotbenutzers	Identitätsteam.
SAML-URLs und -Parameter oder OpenID-Dienstvereinbarung	Administrator des IdP.
Immersiver Kontotreiber, Gruppen und erforderliche Rechte	Immersiver Administrator.

Für SAML muss der Browser in der Lage sein, dem IdP beizutreten und dann die Antwort an die öffentliche RestFrontage-URL weiterzugeben. Für OpenID muss RestFrontage außerdem in der Lage sein, die Tokeninfo- und Benutzerinfo-Dienste des IdP direkt aufzurufen.

Verwalten Sie den operativen Verwaltungszugriff während der Zulassung. Verwenden Sie eine Validierungsumgebung und ein Pilotkonto, bevor Sie die Verbindung verallgemeinern.

2.2 Konfigurationsort

Die Saml- und OpenID-Abschnitte werden geladen, wenn RestFrontage startet. Sie können in den Umgebungskonfigurationsdateien oder durch die Prozessumgebungsvariablen gefüllt werden.

SAML- und OpenID-Dienste behalten die Optionen, die sie bei ihrer Erstellung erhalten haben. Neustart der RestFrontage-Instanz, nachdem du diese Optionen geändert hast, selbst wenn der Konfigurationsanbieter weiß, wie man eine Datei neu lädt.

Beispiele für Namen von Umweltvariablen:

Saml__FidUrl
Saml__FidSsoPath
Saml__FidSloPath
Saml__EntityId
Saml__LoginUrl
Saml__LogoutUrl
OpenID__FidUrl
OpenID__FidAppId
OpenID__FidAppSecret

Beispiel appsettings.json zu diesen beiden Abschnitten:

  "Saml": {
    "FidUrl": "???",
    "EntityId": "???",
    "LoginUrl": "???/api/Saml/Login",
    "LogoutUrl": "???/api/Saml/Logout"
  },
  "OpenID": {
    "FidUrl": "???",
    "FidAppId": "???",
    "FidAppSecret": "???"
  }

3. Externe Benutzer anhängen

3.1 Konfigurieren Sie die Benutzerkarte

1. Öffnen Sie die Kontokarte in RestFrontage Security User Management.
2. Lokalisieren Sie den Block Interoperabilität und offen Interoperabilität verwalten.
3. Jetzt nachfragen Externe Homedomäne um den Ursprungsbereich des Berichts zu beschreiben.
4. Jetzt nachfragen Name des externen Heimkontos mit dem genauen erwarteten Wert des IdP.
5. Speichern Sie die Karte und überprüfen Sie dann, ob das Konto aktiviert ist und ob die Gruppen und Rechte korrekt sind.

Spielfeld	Eigentum	Verwendung in den untersuchten Pfaden
Externe Homedomäne	AssociatedExternalUserDomain	Verfügbares Feld in der Karte; es wird nicht von den untersuchten SAML- und OpenID-Kontosuchen verwendet.
Name des externen Heimkontos	AssociatedExternalUserAccountName	Der Abstimmungsschlüssel, der verwendet wird, um den immersiver Nutzer zu finden.

Beispiel für Korrespondenz zur Vorbereitung:

Daten	Beispiel
Immersiver Kontoname	operator.driver
Bevolkte externe Domäne	UNTERNEHMEN
Eingabe des externen Kontonamens	agent.demo
Erhaltener CN-Wert im SAML	agent.demo
Login-Wert in OpenID empfangen	agent.demo

Das lokale Konto und das externe Konto können unterschiedliche Namen haben. Der vom IdP empfangene Wert muss jedoch mit dem externen Anhängungsfeld übereinstimmen. Genaue Fall- und Zeicheneinstellungen: Der Code führt keine gemeinsame Normalisierung durch, und die Empfindlichkeit einiger SAML-Suchen hängt ebenfalls von der Datenbank ab.

3.2 Bedingungen für immersiven Kontozugriff

Das Konto muss bereits existieren. Automatische Benutzer- oder Gruppenbereitstellung anhand von SAML- oder OpenID-Attributen erscheint in diesen Routen.

Die Ausgabe des Immersive Tokens wird verweigert, wenn das Konto deaktiviert, abgelaufen oder gesperrt wird. Controller prüfen unter anderem IsEnabled, ExpirationDate und LockoutUntilUtc. Ein abgelaufenes Konto wird im Authentifizierungspfad deaktiviert.

Rollen oder Gruppen, die vom IdP weitergegeben werden, werden von diesen Controllern nicht automatisch in Immersive Rights umgewandelt. Weisen Sie Rechte dem Konto oder seinen Gruppen in Immersive zu und überprüfen Sie diese nach der Anmeldung.

4. SAML konfigurieren

4.1 RestFrontage-Parameter

Parameter	Rolle	Fiktives Beispiel
Saml:FidUrl	Die Grundlage der URL des Identitätsanbieters.	https://idp.example.net
Saml:FidSsoPath	Pfad zur Verbindung zu FidUrl hinzugefügt.	/saml/sso
Saml:FidSloPath	Pfad wurde zur FidUrl für föderiertes Ausloggen hinzugefügt.	/saml/slo
Saml:EntityId	Die Kennung des immersiveren Dienstes wurde dem IdP erklärt und im Emittent platziert.	Urn:Beispiel:immersive:Rezept
Saml:LoginUrl	Die öffentliche URL für den Empfang der Verbindungsantwort, oder ACS.	https://rest.example.net/api/Saml/Login
Saml:LogoutUrl	Ausloggen liefert eine öffentliche URL zurück.	https://rest.example.net/api/Saml/Logout

Der Dienst konstruiert die Ziele durch direkte Verkettung von FidUrl und Pfad. Im obigen Beispiel ist das Verbindungsziel https://idp.example.net/saml/sso. Vermeiden Sie doppelte Schrägstriche, fehlende Schrägstriche und Pfade, die bereits eine Abfragefolge tragen: Fügt sich der Dienst selbst hinzu? SAMLRequest=.

FidSloPath und LogoutUrl sind für den Ausloggungspfad. Für eine Verbindung, die diesen Pfad enthält, füllen Sie sie aus und testen Sie sie separat von der Verbindung.

{
  "Saml": {
    "FidUrl": "https://idp.example.net",
    "FidSsoPath": "/saml/sso",
    "FidSloPath": "/saml/slo",
    "EntityId": "urn:example:immersive:recette",
    "LoginUrl": "https://rest.example.net/api/Saml/Login",
    "LogoutUrl": "https://rest.example.net/api/Saml/Logout"
  }
}

Die Pfade /saml/sso und /saml/slo sind veranschaulich. Ersetzen Sie sie durch die vom IdP-Administrator bereitgestellten Adressen. Melden Sie alle öffentlichen Präfixe für RestFrontage in LoginUrl und LogoutUrl.

Siehe die Präsentation der Rest Frontage Configuration File

4.2 Erkläre den Dienst dem IdP

1. Deklarieren Sie die entsprechende immersive Anwendung oder den Dienstanbieter in der Zielumgebung.
2. Melde den EntityId-Wert genau wie die Dienstanbieter-Kennung.
3. Deklarieren Sie LoginUrl als ACS-URL, die die Antwort über HTTP POST empfängt.
4. Für federated Logout deklarieren Sie die LogoutUrl-Rückgabe und prüfen Sie das vom IdP erwartete Verhalten.
5. Konfigurieren Sie die Attribute, die zum Abgleichen des Kontos erforderlich sind, und geben Sie einem Pilotbenutzer die Berechtigung, auf diese Anwendung zuzugreifen.
6. Verifizieren Sie die im Kapitel zu den Limits beschriebenen Unterzeichnungs- und Validierungsanforderungen, bevor Sie die Produktion öffnen.

Der Dienst gibt eine SAML 2.0 AuthnRequest aus, die mit Deflate komprimiert und dann in Base64 und in der URL codiert wird. Er spezifiziert eine HTTP-POST-Rückgabe und eine NameID-Richtlinie im transienten Format. Wenn forceAuthentication wahr ist, fügt er der Anfrage ForceAuthn hinzu.

Diese Eigenschaften müssen vom IdP akzeptiert werden. Der zu prüfende Code stellt in SamlOptions keine SAML-Metadaten-URLs oder eine Option für Signierungszertifikate bereit. Daher reicht es nicht aus, eine MetadataUrl oder einen Zertifikatsparameter zu erfinden, um sie zu aktivieren.

4.3 Erwartete Daten als Antwort

Daten	Verwendung
InResponseTo zur SAML-Antwort	Verwendet als Anfrage-Kennung, um die vom Kunden gestartete Reise zu finden.
SessionIndex in AuthnStatement	Notwendig für die Erkennung der Verbindungsantwort; für das Abloggen beibehalten.
CN-Attribut	Das erste Attribut suchte nach dem externen Kontonamen.
Attribute http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	Alternative wird verwendet, wenn CN fehlt.

Die Kontozuordnung beruht auf einem SAML-Attribut. Das blozte Vorhandensein einer NameID, E-Mail-Adresse oder eines Unterattributs überschreibt nicht cn oder das erwartete Name-Attribut. Ist cn vorhanden, hat es Vorrang vor dem alternativen Attribut.

Konfigurieren Sie einen einfachen, eindeutigen Wert für dieses Attribut. Der Parser behält den ersten AttributeWert jedes Attributs; mehrere Gruppen und Attribute sind kein Mechanismus zur Zuweisung von Rechten.

4.4 Verbindungsweg

Ein Kunde wie der Beholder folgen Sie den folgenden Schritten, um eine Verbindung über SSO herzustellen SAML.

Der Client bereitet automatisch zwei Werte vor, um die Verbindung zu starten. requestId ist ein bei jedem erneuter Versuch generierter Identifikator: Er wird verwendet, um die SAML-Anfrage mit der Rückgabe des Identitätsanbieters zu verknüpfen.

Immersiver Betrachter erzeugt eine GUID und konstruiert eine Identifikator, die auch die Rücksendungsadresse enthält. forceAuthentication ist eine Kundenwahl: False erlaubt es dem Identitätsanbieter, eine bestehende Sitzung gemäß seiner Richtlinie wiederzuverwenden, während true eine erneute Authentifizierung erfordert, selbst wenn eine Sitzung bereits existiert. Der Beholder verwendet standardmäßig falsch. Beide Werte werden vom Kunden verwaltet: Der Administrator muss nichts abrufen oder eingeben.

Die Schritte sind wie folgt:

1. Der Client erstellt eine versuchsspezifische Anfrage-ID und ruft GET auf /api/Saml/GetSamlUrl mit requestId und forceAuthentication.
2. RestFrontage liefert einen JSON-String mit der SAML-Login-URL zurück; dieser Aufruf leitet den Browser nicht direkt um.
3. Der Client öffnet diese URL und der Benutzer authentifiziert sich beim IdP.
4. Nach der Authentifizierung leitet der Identitätsanbieter die Antwort weiter SAML vom Navigator, in HTTP POST, auf die URL in Saml:LoginUrl. In unserem vorherigen Beispiel ist dieser Wert https://rest.example.net/api/Saml/Login : Dies ist der von RestFrontage bereitgestellte Empfangspunkt, um die Bearbeitung der Steuererklärung automatisch abzuwickeln SAML.
5. RestFrontage ruft die erwarteten Daten ab und versucht, die Anfrage und den Sitzungsindex im entsprechenden externen Konto zu speichern.
6. Der Client verschlüsselt die Anforderungs-ID mit dem Immersive Security Context und sendet sie an POST /api/Saml/Authenticate.
7. RestFrontage ruft das Konto ab, überprüft seinen Zustand und gibt ein AuthenticationToken zurück, das das Token und den immersiven Nutzer enthält.

Für Clients, die eine Weiterleitung verwenden, weiß der Code, wie man eine Identifikatorin interpretiert, die ein _redirect= Ziel enthält, möglicherweise hexadezimal codiert. Launcher in RestFrontage erstellen dieses Format. Verwenden Sie den für diese Integration vorgesehene Client, anstatt eine beliebige Rückgabe-URL zu erstellen.

4.5 SAML Logout

Ein authentifizierter immersiver Nutzer kann GET anfordern /api/Saml/GetSamlLogoutUrl mit einem requestId. Der Dienst erstellt die Abmeldungsanfrage vom externen Konto und dem behaltenen SessionIndex. Der IdP gibt dann seine Antwort an /api/Saml/Logout, der akzeptiert HOL DICH und POST.

Abmelden am IdP, das Löschen von Clientdaten und die Nichtvalidierung des Immersiv-Zugriffs sind separate Operationen. Die untersuchte Logout-Rückgabe zeigt eine Seite oder Weiterleitungen an; sie widerruft die Immersiv-Tokens in dieser Methode nicht explizit. Überprüfen Sie das vollständige Verhalten des Clients, bevor Sie das Abmelden für alle Zugriffe als wirksam betrachten.

4.6 Beispiel für eine Verbindung zur Microsoft Entra ID

Dieses Beispiel beschreibt, wie man einen SAML 2.0-Hook aus den vom Client übermittelten Metadaten vorbereitet. Die Entra-Tenant- und Anwendungszugangsdaten, der Clientname, der Hostname und das Benutzerkonto wurden durch Platzhalter ersetzt. Es werden keine tatsächlichen SAML-Zertifikate oder Antworten reproduziert.

Das Lesen der Metadaten bestätigt die vom IdP veröffentlichten Dienste. Es stellt keine Validierung der vollständigen Verbindung durch einen immersiven Spieler dar.

4.6.1 Lesen Sie die Metadaten des Identitätsanbieters

Der Entra-Administrator gibt eine URL wie diese an:

https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/federationmetadata/2007-06/federationmetadata.xml?appid=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

Der erste Kenner bezeichnet den Entra-Mandanten. Der appid-Parameter bezeichnet die betreffende Entra-Anwendung; er ersetzt nicht die für Immersive gewählte SAML EntityID.

Diese Datei kann mehrere Protokollbeschreibungen enthalten. Für SAML 2.0 lesen Sie den Abschnitt IDPSSODescriptor, einschließlich der Elemente SingleSignOnService, SingleLogoutService und KeyDescriptor, die für das Signieren verwendet werden.

Extrahierte Daten	Beispiel für fiktiver Wert	Verwendung
entityID des IdP	https://sts.windows.net/11111111-2222-3333-4444-555555555555/	Identifizieren Sie den vertrauenswürdigen Emittenten beim Validieren der Behauptungen. Dieser Wert sollte Saml:EntityId nicht überschreiben.
SingleSignOnService, HTTP-Redirect	https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/saml2	Das Ziel der Verbindungsanfrage.
SingleLogoutService, HTTP-Redirect	https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555/saml2	Das Ziel der föderierten Ausloggungsanfrage.
Unterzeichnungsurkunde	Öffentliches Zertifikat im KeyDescriptor vorhanden	SAML-Unterschriften überprüfen; auch die Verlängerung planen.

Die Metadaten-URL wird verwendet, um den Identitätsanbieter zu beschreiben. Sie sollte nicht als Anmeldeziel verwendet werden. In dieser Version lädt RestFrontage diese Datei nicht automatisch, und SamlOptions stellt keine Metadaten-, Zertifikats- oder vertrauenswürdigen Ausgabeneinstellungen offen.

4.6.2 Bereite die RestFrontage-Konfiguration vor

In diesem Beispiel ist die Adresse der RestFrontage https://rest.example.net:44348 und die vereinbarte SAML-Kennung für Immersive ist urn:example:immersive:client-example:production.

Melde die entsprechenden Werte im Saml-Abschnitt der tatsächlich von der Umgebung geladenen Konfiguration und starte dann RestFrontage nach Anwendung der Konfiguration neu:

{
  "Saml": {
    "FidUrl": "https://login.microsoftonline.com/11111111-2222-3333-4444-555555555555",
    "FidSsoPath": "/saml2",
    "FidSloPath": "/saml2",
    "EntityId": "urn:example:immersive:client-exemple:production",
    "LoginUrl": "https://rest.example.net:44348/api/Saml/Login",
    "LogoutUrl": "https://rest.example.net:44348/api/Saml/Logout"
  }
}

RestFrontage konstruiert die Adressen des IdP, indem es FidUrl mit FidSsoPath oder FidSloPath verkettet. Füge in diesem Beispiel keinen letzten Schrägstrich zu FidUrl hinzu.

LoginUrl nutzt die eingebaute Rückgafette von RestFrontage, um die Verbindungsantwort automatisch zu verarbeiten. LogoutUrl kennzeichnet die Trennungsrückgabe. Behalten Sie das HTTPS-Schema, den Hostnamen, den Port und jedes Bereitstellungspräfix in den vollen Adressen.

4.6.3 Lassen Sie die Antragserklärung in Entra bestätigen

Der Administrator des Kunden muss die folgenden Werte in der relevanten Unternehmensanwendung überprüfen:

Entra-Parameter	Dummy-Wert zu dokumentieren
Identificateur / Identifier (Entitäts-ID)	urn:beispiel:immersiv:client-beispiel:produktion
Antwort-URL (ACS)	https://rest.example.net:44348/api/Saml/Login
URL de déconnexion / Logout URL	https://rest.example.net:44348/api/Saml/Logout

Die URN- und ACS-URL müssen exakt mit der RestFrontage-Konfiguration übereinstimmen. Die Veröffentlichung der IdP-Metadaten beweist nicht, dass diese Werte gespeichert wurden. Das Abmelden muss separat überprüft werden, insbesondere bei von Entra initiierten Anfragen.

4.6.4 Setzen Sie das Kontoattribut ein und bereiten Sie einen Pilotbenutzer vor

Für dieses Beispiel stimmen Sie zu, das Entra-Login, oder UPN, des Benutzers im folgenden SAML-Attribut weiterzugeben:

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name

In Entra-Attributen und -Claims überprüfen Sie den Namensnamen, den http://schemas.xmlsoap.org/ws/2005/05/identity/claims Namensraum und die Quelle user.userprincipalname. Die tatsächliche Zuordnung muss mit dem Client bestätigt werden; sie kann nicht allein aus den Metadaten abgeleitet werden.

In der Kontokarte des Immersive Treibers füllen Sie AssociatedExternalUserAccountName mit demselben Wert aus, zum Beispiel utilisateur@example.net. Wird auch ein cn-Attribut ausgegeben, hat es Vorrang in der aktuellen Verarbeitung: Es muss fehlen oder den erwarteten Wert für das immersive Konto enthalten.

Das immersive Konto muss bereits existieren, aktiv sein und die notwendigen Rechte besitzen. Weise den Pilotnutzer auch der Entra-App zu. Die aktuelle SAML-Reise erstellt das Konto nicht automatisch oder synchronisiert seine Rechte.

4.6.5 Vollständige SAML-Validierung vor dem Test mit Live-Konten

Die Konfiguration von Adressen reicht nicht aus, um die Verbindung zu sichern. In der hier untersuchten Version werden XML-Attribute extrahiert, ohne die Signatur, den vertrauenswürdigen Aussteller, die Audience, den Empfänger, den SAML-Status und die Zeitbedingungen kryptografisch zu validieren.

Eine Anpassung muss diese Prüfungen, das vom IdP veröffentlichte Zertifikat und dessen Verlängerung unterstützen. Auch die Korrelation zu einer tatsächlich offenen Anfrage und der Schutz vor Wiederholung müssen überprüft werden. Fügen Sie keine Zertifikats- oder Metadatenparameter ohne entsprechende Implementierung hinzu.

4.6.6 Teste die vollständige Reise vom Immersiv-Client aus

Nach dieser Anpassung wird die SAML-Verbindung vom Player oder dem für die Integration bereitgestellten Immersive Launcher gestartet. Dies bereitet requestId und forceAuthentication vor; der Administrator muss diese Werte nicht konstruieren oder die Verbindungsrouten manuell aufrufen.

• Überprüfen Sie die Ankunft bei der Authentifizierung des richtigen Entra-Mieters und des möglichen MFA.
• Überprüfen Sie die HTTP POST-Zurückkehr zur deklarierten LoginUrl-URL.
• Bestätigen Sie, dass das erhaltene Attribut mit dem Immersive Driver-Konto übereinstimmt.
• Bestätigen Sie den Erfolg des finalen Austauschs mit /api/Saml/Authenticate und dem Zugriff auf die erlaubten Funktionen.
• Überprüfen Sie die Ablehnung eines unbekannten oder deaktivierten Immersiver-Kontos.
• Teste die Trennung und das Schicksal von Immersiv-Sitzungen und Tokens getrennt.

Eine LoggedIn=ok-Rückkehrseite oder Umleitung beweist nicht den Erfolg der gesamten Reise. In den untersuchten Reader- und Beholder-Launchern läuft das SSOToken-Tracking-Cookie nach 30 Sekunden ab: Diese Verzögerung muss überprüft werden, um eine interaktive Authentifizierung zu ermöglichen, insbesondere mit MFA.

Die Synchronisation von aktiven, deaktivierten oder gelöschten Konten bleibt eine separate Notwendigkeit, die mit dem Kunden festgelegt werden muss. Das Empfangen von Metadaten und das Aktivieren von SSO führt nicht zur Einrichtung der SCIM-Bereitstellung ein.

5. Konfigurieren Sie die OpenID-Reise

5.1 Unterschied zu einer Standard-OIDC-Verbindung

OpenID Connect ist eine Identitätsschicht, die auf OAuth 2.0. Der Standard definiert unter anderem die Token-ID und den UserInfo-Endpunkt. Siehe OpenID Connect Core-Spezifikation.

Der RestFrontage OpenID-Controller verwendet einen bestimmten Pfad: Der Client hat bereits ein externes Zugriffstoken erhalten, und RestFrontage fragt die Tokeninfo- und Benutzerinfo-Dienste ab. In diesem Pfad werden keine .well-known/openid-Konfiguration, Autorisierungscode-Austausch, Token-ID-Validierung oder Token-Verlängerung konfiguriert.

Daher sind Authority, MetadataAddress, CallbackPath oder eine /signin-oidc-URL keine Parameter des OpenID-Abschnitts. Die Redirect-URLs, Scopes und Methoden zur Beschaffung des Tokens sind in der Integration zwischen der Client-Anwendung und dem IdP zu definieren.

5.2 RestFrontage-Parameter

Parameter	Effektive Rolle
OpenID:FidUrl	Die Basis-URL, die von RestFrontage verwendet wird, um Tokeninfo und Userinfo aufzurufen. Planen Sie einen finalen Schrägstrich, falls die Dienste unter einem Pfad liegen.
OpenID:FidAppId	Identifikator verglichen mit dem client_id, der durch Tokeninfo zurückgegeben wird. Wird für den autorisierten Antrag ausgefüllt.
OpenID:FidAppSecret	Eine Option, die in der Vorlage existiert, aber nicht von den Aufrufen des untersuchten Controllers genutzt wird. Sie aktiviert keine Client-Authentifizierung für Tokeninfo.

Minimales Beispiel der tatsächlich vom Controller verwendeten Parameter:

{
  "OpenID": {
    "FidUrl": "https://idp.example.net/oauth2/",
    "FidAppId": "immersive-recette"
  }
}

Mit dieser Basis werden Aufrufe auf https://idp.example.net/oauth2/tokeninfo und https://idp.example.net/oauth2/userinfo ausgerichtet. Ohne den letzten Schrägstrich nach oauth2 kann das Auflösen einer relativen URL dieses Segment entfernen und auf einen anderen Standort zielen.

Wenn ein anderer Teil Ihrer Integration ein Secret benötigt, stellen Sie ihm den Hosting-Secrets-Mechanismus zur Verfügung. In diesem Controller ändert das Ausfüllen von FidAppSecret nicht das Verhalten ausgehender Aufrufe. Eine Anforderung für Basis-Authentifizierung oder client_secret auf Tokeninfo erfordert eine Anpassung der Integration.

5.3 Erwarteter Token-Vertrag

RestFrontage macht einen GET-Anruf in Bezug auf FidUrl:

tokeninfo?access_token=JETON_ACCES_EXTERNE

Der Controller fügt diesem Aufruf keinen Authentifizierungsheader hinzu. Er erwartet eine JSON-Antwort mit den folgenden verwendeten Feldern:

{
  "access_token": "JETON_ACCES_RETOURNE_PAR_IDP",
  "client_id": "immersive-recette",
  "realm": "/environnement-exemple"
}

Der Wert client_id muss FidAppId sein; dieser Vergleich ignoriert den Fall. Das zurückgegebene access_token Token wird dann verwendet, um userinfo aufzurufen. Das Realm-Feld dient als Parameter für diese zweite Abfrage.

Diese Felder beschreiben den spezifischen Vertrag, der vom Code verbraucht wird. Eine Introspektionsantwort, die nur aktiv, sub oder scope enthält, reicht nicht aus, um diese Reise zu befüllen. Der Controller prüft nicht explizit auf eine aktive boolesche oder expires_in Dauer.

5.4 Erwarteter Vertrag von userinfo

RestFrontage führt dann diesen Aufruf aus, wobei das Realm in der URL kodiert ist:

GET /oauth2/userinfo?realm=%2Fenvironnement-exemple HTTP/1.1
Host: idp.example.net
Authorization: Bearer JETON_ACCES_RETOURNE_PAR_IDP

Die JSON-Antwort muss das Anmeldefeld enthalten, das zum Finden des Immersiv-Kontos verwendet wird:

{
  "sub": "identifiant-externe-stable",
  "login": "agent.demo"
}

In diesem Pfad erfolgt das Matching beim Login. Der Controller stimmt das Konto nicht von Sub-, E-Mail-Adresse oder einer Gruppe ab. Das Anmeldefeld ist eine Voraussetzung für diese Integration; es ist kein Attribut, das von allen OIDC-Anbietern garantiert wird.

Der Standard sieht die Überprüfung der Konsistenz des Subs zwischen UserInfo und der Token-ID vor. Diese Überprüfung wird nicht auf dem untersuchten Pfad durchgeführt, der die Token-ID nicht validiert. Siehe UserInfo in OpenID Connect Core.

5.5 Verbindungsweg

1. Die Client-Anwendung erhält ein externes Zugriffstoken vom IdP gemäß ihrer eigenen Anmeldereise.
2. Es kann GET /api/OpenID/CheckToken aufrufen, wobei das Token als Parameter dient, um die Tokeninfo- und Userinfo-Börsen zu überprüfen.
3. Es ruft den Immersive Security Context ab, verschlüsselt das externe Token und sendet es an POST /api/OpenID/Authenticate.
4. RestFrontage ruft Tokeninfo auf, vergleicht client_id und ruft dann userinfo auf.
5. RestFrontage bringt den Login näher an das immersivere Konto, überprüft dessen Status und gibt einen AuthenticationToken zurück.

Beide OpenID-Routen erfordern, dass der Authorization-Header geparst werden kann. Die Werte in diesem Header werden jedoch nicht von der privaten CheckToken-Methode ausgenutzt: Das tatsächlich verarbeitete Token stammt je nach Route vom entschlüsselten Token-Parameter oder -Body. Der empfangene Header authentifiziert daher die Client-Anwendung in diesem Pfad nicht von selbst.

6. Konfigurieren Sie die Client-Anwendung und den Zugriff

6.1 Ermöglichen Sie die richtige Kundenreise

Serveroptionen wählen in allen Client-Anwendungen nicht automatisch den Verbindungsmodus aus. Der Launcher oder Client muss für das erwartete Protokoll und für die RestFrontage-URL konfiguriert werden.

Der Wert von Login.Modes in der UserInfos.txt des Betrachters mindestens die SAML um die Verbindung über SAML und/oder zu ermöglichen OIDC für OpenId.

Beispiel: Der folgende Wert erlaubt es einem Betrachter, den Standard-Login in Login/Passwort über Immersive Accounts, aber auch in SAML und OIDC :

"Login.Modes" : "SAML|OIDC|DEFAULT"

Die untersuchten Reader- und Beholder-Skripte behalten die SSO-ID in einem SSOToken-Cookie für 30 Sekunden. Eine langsame Verbindung oder ein mehrfaktoriger Schritt kann diese Zeit überschreiten: Wenn die SAML-Rückgabe erfolgreich ist, der Launcher die Verbindung aber neu startet, überprüfen Sie diesen Punkt in der bereitgestellten Client-Version.

6.2 Nutzen Sie den Immersive Security Context

GET /api/Security/Context stellt ein SecurityToken bereit, das den öffentlichen Verschlüsselungsschlüssel enthält. Die Authenticate-Routen warten dann auf ein Verschlüsselter JSON-String mit dem immersiv-kompatiblen RSA-Mechanismus.

Straße	Daten zu quantifizieren
POST /api/Saml/Authenticate	Die Anfrage-ID wurde nach der SAML-Rückgabe erkannt.
POST /api/OpenID/Authenticate	Externer Zugriffstoken, der vom IdP erhalten wurde.

Die HTTP-Körperform ist eine JSON-Zeichenkette, wie in diesem Beispiel einer nicht ausführbaren Struktur:

"DONNEE_CHIFFREE_PAR_LE_CLIENT_IMMERSIVE"

Dieser Körper ist kein Objekt, das encryptedData, eine Klartextkennung oder SAML-XML enthält. Verwenden Sie die kompatible Verschlüsselungsimplementierung, die dem Client zur Verfügung gestellt wird. Der öffentliche Schlüssel überschreibt HTTPS nicht.

6.3 Überprüfen Sie die Rechte nach dem Login

Nach der Ausgabe des Tokens wird die tatsächlich zurückgegebene Immersive Identität, die Gruppen des Kontos und seine Rechte an den notwendigen Funktionen und Objekten überprüft. Teste außerdem eine Funktion, die dem Pilotkonto verboten bleiben muss.

SAML- und OpenID-Controller stellen keinen globalen Anspruch dar. SSO stellt die Identität fest; die Autorisierungsregeln der Plattform bestimmen dann den Zugriff.

7. Streckenreferenz

Methode und Route	Verwendung	Erwarteter Kontext
GET /api/Security/Context	Stellt den Immersive Public Key bereit.	Vor der Authentifizierung zugänglich.
GET /api/Saml/GetSamlUrl	Gibt die IdP-URL als JSON-String zurück.	requestId und forceAuthentication; vor der Authentifizierung zugänglich.
POST /api/Saml/Login	Erhält die Verbindung SAML-Rückgabe.	SAML-Antwort, die vom Browser vom IdP übertragen wird.
POST /api/Saml/Authenticate	Tauscht die SAML-Anfrage gegen ein Immersive Token aus.	Eine Identifikator, die in einem JSON-String verschlüsselt ist.
GET /api/Saml/GetSamlLogoutUrl	Gibt die IdP-Logout-URL zurück.	Authentifizierter immersiver Nutzer und requestID.
GET oder POST /api/Saml/Logout	Erhält die SAML-Abmelde-Rückgabe.	SAMLResponse in dem vom Controller erwarteten Format.
GET /api/OpenID/CheckToken	Führt die externen Verifizierungsaufrufe aus.	token als Abfrageparameter und parsabler Autorisierungsheader.
POST /api/OpenID/Authenticate	Tauscht den externen Token gegen einen Immersiv-Token.	Ein externes Token, verschlüsselt in einem JSON-String und einem parsablen Autorisierungsheader.

Die direkte Kontrolle über das OpenID-Token platziert es in der URL, genau wie beim ausgehenden Aufruf von Tokeninfo. Vermeiden Sie es, diese URLs mit ihren Parametern in Zugriffsprotokollen oder in einem ungeschwärzten Support-Ordner zu speichern.

8. Tests der Verbindung

8.1 Häufige Prüfungen

• Die URLs entsprechen der Zielumgebung und sind über die relevanten Komponenten zugänglich.
• Die eigentliche Konfiguration berücksichtigt alle Gemeinkosten; RestFrontage wurde neu gestartet.
• Das Pilotkonto existiert, hat einen eindeutigen externen Kontonamen und ist aktiviert, nicht abgelaufen und nicht gesperrt.
• Ein vollständiger Login liefert den korrekten Nutzer und ein Immersiver-Token.
• Das Konto greift auf eine autorisierte Funktion zu, kann aber nicht auf eine verbotene Funktion zugreifen.
• Ein externer Nutzer ohne ein passendes Immersivers-Konto erhält kein Immersivers-Token.
• Ein deaktiviertes, abgelaufenes oder gesperrtes Immerve-Konto erhält kein Token.
• Das Trennen, Schließen des Clients und das Wiederverbinden wurden separat überprüft.

8.2 SAML-Prüfungen

• Die generierte URL ist für die korrekte Zieladresse und die Anfrage enthält die korrekte EntityId und ACS.
• Die Rückgabe erreicht /api/Saml/Login mit InResponseTo, SessionIndex und dem erwarteten Kontoattribut.
• Die Verbindung reicht bis /api/Saml/Authenticate; die Rückgabeseite allein wird nicht als Beweis verwendet.
• Ein erneuter Versuch verwendet eine neue Anfrage-Identifikator; das Wiederholungspräventionsverhalten wird kontrolliert.
• Eine Reise mit Multi-Faktor-Authentifizierung oder langsamem Login endet ebenfalls im bereitgestellten Client.
• Die Garantien der Validierung der im nächsten Kapitel präsentierten Behauptungen sind tatsächlich vorhanden, bevor die Produktion in Produktion aufgenommen wird.

8.3 OpenID-Verifizierungen

• Laut RestFrontage löst FidUrl Tokeninfo und Benutzerinfo korrekt auf.
• tokeninfo stellt die erforderlichen Felder bereit und client_id entspricht FidAppId.
• UserInfo bietet einen nicht leeren Login für das Pilotkonto.
• Ein Token, das abgelaufen, widerrufen oder für einen anderen Antrag ausgestellt wurde, wird auf dem gesamten Pfad abgelehnt.
• Die Authentifizierungsanforderungen der IdP-Dienste sind mit den tatsächlich getätigten Anrufen kompatibel.
• Die Kompatibilität der Client-Anwendung, des IdP, und dieser Version von RestFrontage ist über eine einzelne Rückgabe von 204 hinaus etabliert.

Diese Punkte sind ein Testplan, der ausgeführt werden soll. Sie beschreiben keine Tests, die bereits auf einem Server oder IdP durchgeführt wurden.

9. Diagnose häufiger Schwierigkeiten

Symptom	Prioritätsprüfung
Die SAML-Login-URL ist ungültig	Überprüfe die FidUrl + FidSsoPath-Konkatenation und die Konfiguration wurde tatsächlich geladen.
IdP lehnt SAML-Anfrage ab	Vergleichen Sie EntityId, ACS, Bindung, NameID-Richtlinie und Unterzeichnungsanforderungen mit der IdP-Deklaration.
Die Verbindungsrückgabe zeigt einen Fehler oder bleibt ohne nützliches Ergebnis	Überprüfen Sie das Format der Rückgabe, InResponseTo, SessionIndex, cn oder des alternativen Namensattributs. Ein einfacher, erfolgreicher HTTP-Code ist kein vollständiger Verbindungsnachweis.
Die Rückgabeseite erscheint, aber Authenticate schlägt fehl	Verifizieren Sie das externe Konto, die übertragene Anfrage-ID, deren möglichen Verbrauch und die Verschlüsselung des Körpers.
Der Launcher läuft nach der Rückkehr von SAML in Schleifen	Überprüfen Sie die Cookies, das Rückkehrziel und die 30-Sekunden-Dauer von SSOToken in den betroffenen Launchern.
Ungültige Anfrage für einen beliebigen Benutzer in OpenID	Überprüfen Sie beide IdP-Anrufe, client_id, Login und die Verbindung zum Immerve-Konto.
CheckToken gelingt, aber Authenticate scheitert	Überprüfen Sie die Existenz und den Status des Immersiv-Kontos sowie die Verschlüsselung des externen Tokens.
tokeninfo oder userinfo gibt 404 zurück	Überprüfe FidUrl, seinen letzten Schrägstrich und die tatsächlichen Pfade des IdP.
Der IdP verlangt ein Geheimnis, obwohl FidAppSecret besetzt ist	Der Controller nutzt diese Geheimhaltung nicht für seine Anrufe; lass die Verbindung anpassen.
Das Konto wird als gesperrt oder deaktiviert gemeldet	Prüfe IsEnabled, ExpirationDate und LockoutUntilUtc im immersiveren Konto.
Die Verbindung gelingt, aber der Geschäftszugang wird verweigert	Überprüfe immersive Autorisierungen; externe Authentifizierung gewährt keine Geschäftsrechte.
Der IdP-Ausloggen stoppt nicht den gesamten Zugriff	Verifizieren Sie die Sitzungsdaten des Kunden und den Lebenszyklus des Immersive Tokens.

Protokolle können "SSO-Login für externe CN anfordern", "SSO-Login für externe CN", "SSO-Login fehlgeschlagen für Anfrage" oder ein deaktiviertes oder gesperrtes Konto-Ereignis enthalten. Korpositionieren Sie Zeit, Fahrerkonto und Reisephase. Reduzieren Sie Token, SAML-Antworten und persönliche Daten vor der Übermittlung von Traces.

10. Einschränkungen der zu prüfenden Version

10.1 SAML-Validierung wird vor einer Produktionsexposition verarbeitet

Der untersuchte Pfad entschlüsselt die SAML-Antwort und extrahiert deren Attribute. Er zeigt keine kryptografische Verifikation von Signatur, IdP-Vertrauenskette, Audience, Empfänger, SAML-Status oder Zeitbedingungen der Behauptung. Keine IdP-Zertifikats- oder Metadatenoptionen werden von SamlOptions offengelegt.

Daher beweist das Vorhandensein dieser Daten in einer Antwort nicht ihre Echtheit. Die Anforderungen zur Validierung des SSO-Profils sind in der OASIS SAML 2.0 Profile, Abschnitt 4.1.

Der Code speichert den Anforderungs- und Sitzungsindex im Codefeld des Benutzers. Er versucht, die Anfrage-ID zu löschen, wenn sie gegen ein Token ausgetauscht wird. Dieser Konsum ist keine Signaturprüfung und reicht nicht aus, um vollständigen Schutz vor Wiederholung zu demonstrieren; das Ergebnis der Erasure-Methode wird vom Aufrufer nicht als Erfolgsbedingung auferlegt.

Der Parser liest außerdem den Körper der SAML-Rückgabe als Zeichenkette und entfernt das Präfix SAMLResponse=. Er behandelt diesen Körper nicht als vollständige Menge von Formfeldern. Rezeptiere die tatsächlichen Antworten des IdP, insbesondere wenn sie RelayState oder andere Felder enthalten.

10.2 OpenID-Kompatibilität wird noch bestätigt

Der Code steuert client_id und nutzt dann den Login aus. Er implementiert keine generische OIDC-Token-Validierung und auch kein stabiles Match basierend auf dem Emittent- und Subjektpaar. Er prüft nicht explizit aktive, Scopes oder Ablauf in Tokeninfo. Die Ablehnung eines widerrufenen oder abgelaufenen Tokens muss daher im tatsächlichen Verhalten der IdP-Dienste und im vollständigen Rezept bestätigt werden.

Das konfigurierte Geheimnis wird in diesem Pfad nicht verwendet. Empfangene Autorisierungsheader dienen nicht als Identitätsnachweis für den anrufenden Client. Diese Punkte begrenzen kompatible IdP-Verträge und sollten berücksichtigt werden, wenn eine Client-Authentifizierung erforderlich ist.

Bewerben Sie keine validierte Kompatibilität mit Microsoft Entra ID, Keycloak, AD FS oder einem anderen Anbieter allein auf der Existenz von SAML- und OpenID-Routen. Jeder Anbieter und jede Version erfordert einen Vertrag und eine vollständige Pfadverifikation.