Claim Transforms und Claim Tasks

Jede FoxIDs Authentifizierungsmethode und Anwendungsregistrierung verarbeitet Claims und unterstützt Claim Transforms und Claim Tasks. Das bedeutet, dass mehrere Sätze von Claim Transforms und Claim Tasks für jede Benutzerauthentifizierung ausgeführt werden können. Zuerst werden Claim Transforms und Claim Tasks an der Authentifizierungsmethode ausgeführt und danach an der Anwendungsregistrierung.

Zusätzliche Teilmengen von Claim Transforms und Claim Tasks können ausgeführt werden, wenn ein Benutzer oder ein externer Benutzer erstellt wird.

Claim transform flow diagram

Bei Authentifizierungsmethoden mit einer Liste Forward claims müssen gewöhnliche Claims aus Transformationen der ersten Ebene zu dieser Liste hinzugefügt werden, damit sie in nachfolgenden Schritten verfügbar sind. Alternativ kann die Liste * (Standard) enthalten. Login Authentifizierungsmethoden geben diese Claims ohne diese Liste weiter.

Die reservierten Präfixe _local:, _internal:, _session: und _impersonate: bestimmen, wie Claims während der Authentifizierung verwendet werden. Die unterschiedlichen Lebensdauern sind unter Lokale, interne und Sitzungsclaims beschrieben.

Um einen gewöhnlichen Claim aus einer Anwendungsregistrierung auszustellen, fügen Sie ihn oder * zu Issue claims hinzu. Bei OpenID Connect können Sie ihn alternativ zu den Voluntary claims eines Scopes hinzufügen und diesen Scope aus der Anwendung anfordern. Reservierte Claims werden auch mit * nicht ausgestellt.

Bitte sehen Sie die Claim Transform Beispiele.

Aktivieren Sie Log claim trace in den Log settings, um die Claims vor und nach der Transformation in den Logs zu sehen.

Claim Transforms können in einer Login Authentifizierungsmethode konfiguriert werden.

FoxIDs authentication method claim transform

Und Claim Tasks.

FoxIDs authentication method claim task

Ebenso können Claim Transforms und Claim Tasks als First Level und Second Level in einer OpenID Connect Authentifizierungsmethode konfiguriert werden.

FoxIDs application registration claim transform

Claims werden standardmäßig als JWT Claims dargestellt. Wenn die Authentifizierungsmethode SAML 2.0 ist, werden die First Level Claims als SAML 2.0 Claims dargestellt. Wenn die Anwendungsregistrierung SAML 2.0 ist, werden die Claims als SAML 2.0 Claims dargestellt.

Ein Claim Transform und Claim Task führt eine von bis zu sieben verschiedenen Aktionen aus, abhängig vom jeweiligen Typ.

Claim Transform und Claim Task Aktionen:

  • Add claim - neues Claim hinzufügen
  • Add claim, if not match - Add Aktion ausführen, wenn die Bedingung nicht zutrifft
  • Replace claim - neues Claim hinzufügen und bestehende Claims entfernen, wenn eine oder mehrere vorhanden sind
  • Replace claim, if not match - Replace Aktion ausführen, wenn die Bedingung nicht zutrifft
  • Remove claim - Claims entfernen, wenn eine oder mehrere vorhanden sind
  • If match - Aktion ausführen, wenn die Bedingung zutrifft
  • If not match - Aktion ausführen, wenn die Bedingung nicht zutrifft

Claim Transforms und Claim Tasks werden in der Reihenfolge ausgeführt, und die Aktionen werden daher in der Reihenfolge ausgeführt. Das bedeutet, dass es möglich ist, eine lokale Variable zu erstellen, indem ein Claim hinzugefügt wird und später in der Sequenz Entscheidungen auf Basis des Claims getroffen werden. Ein Claim ist lokal im Claim Transforms und Claim Tasks Satz, wenn es mit _local: beginnt.

Wenn Claim Transforms und Claim Tasks in einem Login Flow laufen, fügt FoxIDs automatisch lokale Claims aus der Login Request hinzu, bevor die Transformationen ausgeführt werden. Diese _local: Claims sind für Entscheidungen innerhalb der Transform Task Sequenz gedacht und werden aus dem Output entfernt.

Allgemeine lokale Claims aus der Anmeldeanfrage:

  • _local:login_action - Login Request Aktion, gespeichert als camelCase
  • _local:user_id - Login Request User ID (nur wenn angegeben)
  • _local:max_age - Login Request max age (nur wenn gesetzt und größer als 0)
  • _local:login_hint - Login Request hint (nur wenn angegeben)
  • _local:acr - Login Request ACR Werte als space delimited Liste (nur wenn angegeben)
  • _local:params:{name} - ein zulässiger Anfrageparameter der Anwendung, mit dem Parameternamen in Kleinbuchstaben und einem Claim pro Wert (nur falls übergeben)

Wenn eine Authentifizierungsmethode als Element von Advanced MFA verwendet wird, erhalten ihre eigenen Claim-Transformationen die folgenden lokalen Claims für den Benutzer, der bereits durch die Login-Authentifizierungsmethode authentifiziert wurde:

Claim Wert
_local:mfa:user_id Die stabile technische FoxIDs-Benutzer-ID des Benutzers.
_local:mfa:user_identifier Die bei der Login-Authentifizierung verwendete Kennung. Wenn keine Kennung angegeben wurde, verwendet FoxIDs die E-Mail-Adresse, Telefonnummer oder den Benutzernamen des Benutzers.
_local:mfa:username Der registrierte Benutzername des Benutzers.
_local:mfa:email Die registrierte E-Mail-Adresse des Benutzers oder der Wert seines Claims email, wenn die registrierte E-Mail-Adresse leer ist.
_local:mfa:phone Die registrierte Telefonnummer des Benutzers oder der Wert seines Claims phone_number, wenn die registrierte Telefonnummer leer ist.

Nur Claims mit einem nicht leeren Wert werden hinzugefügt. Diese Transformationen verarbeiten die vom externen Identitätsanbieter zurückgegebenen Claims und können den vom MFA-Element benötigten AMR-Wert hinzufügen. Der Login-MFA-Ablauf verwendet die transformierte Antwort, um diesen AMR-Wert zu validieren. Andere von der Authentifizierungsmethode zurückgegebene Claims werden weder mit den Claims der Login-Authentifizierungsmethode zusammengeführt noch an deren allgemeine Claim-Transformationen übergeben.

Mit der Aktion Add claim, if not match ist es möglich, ein Claim (lokale Variable) hinzuzufügen, wenn ein anderes Claim oder ein Claim Wert nicht existiert.

Claim Transform Typen, die alle Aktionen unterstützen:

  • Match claim - prüft, ob der ausgewählte Claim Typ vorhanden ist. Bei Add- und Replace-Aktionen wird der ausgehende Claim mit dem neuen Wert geschrieben, wenn der Claim vorhanden ist. if not match-Aktionen werden ausgeführt, wenn der Claim fehlt. Eine Remove-Aktion entfernt den ausgewählten ausgehenden Claim, wenn der Claim vorhanden ist.
  • Match claim and value - prüft, ob der ausgewählte Claim Typ mit dem konfigurierten Wert vorhanden ist. Bei Add- und Replace-Aktionen wird der ausgehende Claim mit dem neuen Wert geschrieben, wenn Claim Typ und Wert übereinstimmen. if not match-Aktionen werden ausgeführt, wenn der Claim vorhanden ist, der Wert aber nicht übereinstimmt. Eine Remove-Aktion entfernt den ausgewählten ausgehenden Claim, wenn Claim Typ und Wert übereinstimmen.
  • Regex match - prüft, ob der ausgewählte Claim Typ vorhanden ist und der Claim Wert dem konfigurierten regulären Ausdruck entspricht. Bei Add- und Replace-Aktionen wird der ausgehende Claim mit dem neuen Wert geschrieben, wenn der reguläre Ausdruck übereinstimmt. if not match-Aktionen werden ausgeführt, wenn der Claim vorhanden ist, der Wert aber nicht dem regulären Ausdruck entspricht. Eine Remove-Aktion entfernt den ausgewählten ausgehenden Claim, wenn der reguläre Ausdruck übereinstimmt.

Claim Transform Typen, die Add claim, Replace claim und Add claim, if new claim does not exist unterstützen:

  • Map - kopiert den ausgewählten Claim Wert in den ausgehenden Claim. Mit Add claim, if new claim does not exist wird der Wert nur geschrieben, wenn der ausgehende Claim noch nicht vorhanden ist.
  • Regex map - extrahiert die benannte Regex Gruppe map aus dem ausgewählten Claim Wert und schreibt den extrahierten Wert in den ausgehenden Claim. Mit Add claim, if new claim does not exist wird der Wert nur geschrieben, wenn der ausgehende Claim noch nicht vorhanden ist.

Claim Transform Typen, die Add claim und Replace claim unterstützen:

  • Constant - schreibt immer den konfigurierten konstanten Wert in den ausgehenden Claim.
  • Concatenate - erstellt den ausgehenden Claim aus Werten der ausgewählten Claims. Der Formatstring verwendet Platzhalter wie {0}, {1} und {2} für die ausgewählten Claim Werte in Reihenfolge.
  • External claims API - sendet ausgewählte Claims an ein externes API. Vom API zurückgegebene Claims werden hinzugefügt oder ersetzen ausgehende Claims.
  • Impersonation - bereitet ein ausgewähltes lokales Target als effektiven Benutzer nach den Transformationen der Authentifizierungsmethode vor. Siehe Impersonation.
  • DK XML privilege to JSON - konvertiert einen DK privilege XML Claim zu JSON Claims, einen Claim für jedes PrivilegeGroup XML Element.

Claim Task Typen, die Add claim und Replace claim unterstützen:

  • Query internal user - verwendet den Lookup Claim Wert, um genau einen internen Benutzer zu finden, und fügt danach ausgewählte Claims dieses internen Benutzers im aktuellen Claim Set hinzu oder ersetzt sie.
  • Query external user - verwendet den Lookup Claim Wert, um genau einen externen Benutzer zu finden, und fügt danach ausgewählte Claims dieses externen Benutzers im aktuellen Claim Set hinzu oder ersetzt sie.
  • Save claim on internal user - verwendet den Lookup Claim Wert, um genau einen internen Benutzer zu finden, und fügt danach den ausgewählten Claim auf diesem internen Benutzer mit Werten aus dem ausgewählten Update Value Claim im aktuellen Claim Set hinzu oder ersetzt ihn.
  • Save claim on external user - verwendet den Lookup Claim Wert, um genau einen externen Benutzer zu finden, und fügt danach den ausgewählten Claim auf diesem externen Benutzer mit Werten aus dem ausgewählten Update Value Claim im aktuellen Claim Set hinzu oder ersetzt ihn.

Alle vier oben aufgeführten Benutzer-Tasks behandeln einen Benutzer als nicht verfügbar, wenn das Konto direkt oder durch eine aktive Mitgliedschaft in einer Zugriffsstruktur deaktiviert ist. Der Benutzer wird ausgeschlossen, bevor FoxIDs ermittelt, ob die Suche genau einen Benutzer gefunden hat. Dadurch fügen Query-Tasks keine Claims hinzu und Save-Tasks nehmen keine Änderungen vor.

Wenn einer der beiden Query-Tasks für Benutzer auf einer Authentifizierungsmethode ausgeführt wird und dem aktuellen Authentifizierungsresultat noch kein lokales Konto zugeordnet ist, wird der erste eindeutig zugeordnete Benutzer in der Ausführungsreihenfolge der Claim-Transformationen zum lokalen Konto des Resultats. Ein Query internal user-Task mit Target liefert nur lokale Claims und lässt diese Kontozuordnung unverändert. Wenn die Authentifizierung über Extended UI-Schritte fortgesetzt wird, bewahrt FoxIDs den Zugriffssnapshot des ausgewählten Kontos in der serverseitigen Sequenz auf und verwendet ihn beim Abschluss des Resultats. FoxIDs wendet die Zuordnung anschließend auf aktive Sessions und Refresh-Token-Grants an. Ein interner oder verbundener externer Benutzer, der direkt durch die Authentifizierungsmethode authentifiziert wird, hat Vorrang, und eine bestehende Zuordnung wird nie durch eine spätere Query ersetzt.

Wenn eine Claim-Transformation interaktiv eine andere Authentifizierungsmethode startet, wird die umgeleitete Authentifizierung als neuer Login Flow ausgeführt. Eine durch eine frühere Query ausgewählte lokale Kontozuordnung wird nicht durch diese Umleitung übernommen.

Query-Tasks für Benutzer auf einer Anwendungsregistrierung können Claims hinzufügen, erstellen oder ändern aber nicht die lokale Kontozuordnung des Logins.

Die Query-Tasks für Benutzer stellen die stabile ID des ausgewählten Benutzers als lokalen Claim bereit:

Claim task Lokaler Claim Wert
Query internal user _local:internal_user_id Die stabile technische FoxIDs-Benutzer-ID des ausgewählten internen Benutzers.
Query external user _local:external_user_id Die stabile technische FoxIDs-ID des ausgewählten externen Benutzers.

Wählen Sie den lokalen Claim explizit in den outgoing claims des Tasks oder wählen Sie *, um ihn für nachfolgende Transformationen in derselben Sequenz verfügbar zu machen. Lokale Claims werden aus der endgültigen Ausgabe entfernt, sofern ihr Wert nicht einem nicht lokalen Claim zugeordnet wird.

Nach der Suche eines internen Benutzers anhand von E-Mail-Adresse oder Benutzername kann beispielsweise ein Match claim and return error-Task _local:internal_user_id prüfen und den Flow beenden, wenn kein eindeutiger interner Benutzer gefunden wurde. Eine Match claim-Transformation kann stattdessen nur dann einen weiteren Claim hinzufügen, wenn die Suche erfolgreich ist. Die stabile Benutzer-ID bleibt lokal in der Transformationssequenz und bietet dennoch eine zuverlässige Grundlage für nachfolgende Entscheidungen.

Bei Query internal user und Save claim on internal user wird der Lookup Claim aus dem aktuellen Claim Set gelesen. Der Wert Lookup claim on internal user definiert, wie der interne Benutzer abgeglichen wird:

  • sub entspricht der User ID des internen Benutzers.
  • email, phone_number und preferred_username suchen zuerst in den Identifiers des internen Benutzers mit einem Abgleich ohne Beachtung der Groß-/Kleinschreibung, sofern Groß-/Kleinschreibung relevant ist. Wenn kein Benutzer über einen Identifier gefunden wird, wird die Suche in den gespeicherten Claims des Benutzers fortgesetzt.
  • Die Suche wird danach in den gespeicherten Claims des internen Benutzers nach demselben Claim Typ und einem Wert fortgesetzt, der ohne Beachtung der Groß-/Kleinschreibung übereinstimmt. Das gilt für alle Lookup Claim Typen, wenn zuerst kein Benutzer gefunden wurde.

Wenn die Suche genau einen internen Benutzer findet, fügt Query internal user ausgewählte Claims dieses Benutzers im aktuellen Claim Set hinzu oder ersetzt sie. Save claim on internal user fügt den ausgewählten Claim auf diesem Benutzer mit Werten aus dem ausgewählten Update Value Claim hinzu oder ersetzt ihn. Wenn kein Benutzer gefunden wird oder wenn über Claims mehr als ein Benutzer gefunden wird, werden keine internen Benutzerclaims hinzugefügt oder gespeichert.

Bei Query external user und Save claim on external user wird der Lookup Claim aus dem aktuellen Claim Set gelesen und gegen die ausgewählte externe Benutzerquelle abgeglichen. Verwenden Sie link_claim als Lookup Claim auf dem externen Benutzer, um über den Link Claim Wert des externen Benutzers abzugleichen.

Claim Task Typen, die If match und If not match unterstützen:

  • Match claim and return error - gibt einen Fehler zurück, wenn der Claim Typ übereinstimmt oder nicht übereinstimmt.
  • Match claim and value and return error - gibt einen Fehler zurück, wenn Claim Typ und Claim Wert übereinstimmen oder nicht übereinstimmen.
  • Regex match and return error - gibt einen Fehler zurück, wenn Claim Typ und Claim Wert dem regulären Ausdruck entsprechen oder nicht entsprechen.
  • Match claim and log event - schreibt den ausgewählten Claim Wert in das Log, wenn der Claim Typ übereinstimmt.
  • Match claim and start authentication - startet einen neuen Login Flow durch Initiieren einer Authentifizierungsmethode, wenn der Claim Typ übereinstimmt oder nicht übereinstimmt.
  • Match claim and value and start authentication - startet einen neuen Login Flow durch Initiieren einer Authentifizierungsmethode, wenn Claim Typ und Claim Wert übereinstimmen oder nicht übereinstimmen.
  • Regex match and start authentication - startet einen neuen Login Flow durch Initiieren einer Authentifizierungsmethode, wenn Claim Typ und Claim Wert dem regulären Ausdruck entsprechen oder nicht entsprechen.

Für Return Error Tasks wird der Protokollfehler konfiguriert, der an den Client oder Requester zurückgegeben wird. OpenID Connect und OAuth 2.0 Konfigurationen geben einen Error und optional eine Error Description zurück. SAML 2.0 Konfigurationen geben einen SAML Statuscode und eine Message zurück.

Die Start Authentication Claim Tasks können für Step-up genutzt werden, wenn der Benutzer mit einem Faktor angemeldet ist und ein weiterer Faktor erforderlich ist, oder wenn zusätzliche Informationen (Claims) erforderlich sind.

Einen internen Benutzer in lokale Claims laden

Setzen Sie das optionale Target für Query internal user, um die Claims eines anderen Benutzers für Prüfungen oder Transformationen zu laden und dabei die lokale Kontozuordnung der Anmeldung beizubehalten. Geben Sie einen Namen wie target ein; FoxIDs fügt _local: hinzu und stellt den Namen jedem ausgewählten Claim-Typ voran:

Ausgewählter Claim Lokales Ergebnis mit Target target
sub _local:target:sub
email _local:target:email
role _local:target:role
_local:internal_user_id _local:target:_local:internal_user_id
_local:access_node _local:target:_local:access_node
_local:access_claim _local:target:_local:access_claim
_local:access_path_claim _local:target:_local:access_path_claim

Der vollständige ursprüngliche Claim-Typ bleibt unter dem Target-Namen erhalten. Dadurch bleiben lokale Hilfsclaims für Konten und Access Structure von gewöhnlichen Claims unterscheidbar. Die Abfrage enthält Claims aus aktiven Access Structure Mitgliedschaften unter Berücksichtigung der Einstellung Forward claims der Struktur sowie lokale Hilfsclaims für Mitgliedschaftsprüfungen.

Wählen Sie Claims anhand ihrer ursprünglichen Namen in Claims from internal user aus, oder verwenden Sie *. Der vollständige lokale Claim-Name einschließlich Präfix und Target-Name muss innerhalb der Grenze von 100 Zeichen liegen. Lassen Sie Target leer, um die ausgewählten Claims direkt in der aktuellen Claim-Sammlung hinzuzufügen oder zu ersetzen.

Mehrere Abfragen und Claims API-Aufrufe können dasselbe Target befüllen. Add claim fügt die zurückgegebenen Werte hinzu. Replace claim ersetzt die Werte der zurückgegebenen Claim-Typen unter diesem Target und behält die übrigen dort vorhandenen Claims bei.

Verwenden Sie die Target-Claims in nachfolgenden Transformationen desselben Satzes. Prüfen Sie beispielsweise _local:target:role, oder ordnen Sie _local:target:sub dem Claim _internal:selected_user_id zu, um den Wert für spätere Transformationssätze zu erhalten. Lokale Target-Claims werden am Ende des Satzes entfernt.

Lokale, interne und Sitzungsclaims

Mit diesen Präfixen wählen Sie die Lebensdauer eines Werts für Claim-Transformationen und Claim-Aufgaben. Ein Transformationssatz ist eine geordnete Liste von Transformationen und Aufgaben, etwa die erste Ebene einer Authentifizierungsmethode, eine Extended UI Liste, die zweite Ebene oder die Liste einer Anwendungsregistrierung. Der Wechsel zu einem anderen Satz ist auch dann relevant, wenn beide zur selben Authentifizierungsmethode gehören.

Präfix Verwendungszweck Verfügbarkeit des Werts Bei einer späteren Anwendungsanmeldung verfügbar?
_local: Vorübergehender Wert oder Entscheidung innerhalb eines Satzes Nachfolgende Transformationen und Aufgaben desselben Satzes. Wird am Ende des Satzes entfernt. Nein. FoxIDs kann in einem neuen Satz neuen lokalen Anfrage- oder Aufgabenkontext bereitstellen.
_internal: Wert für spätere Sätze im aktuellen Authentifizierungsablauf Transformationen der Authentifizierungsmethode, Fortsetzungen wie Extended UI und Anwendungstransformationen. Wird entfernt, bevor die Protokollantwort FoxIDs verlässt. Nein. Erstellen oder kopieren Sie den Wert im neuen Ablauf erneut.
_session: Kleiner Wert, der für denselben authentifizierten Benutzer erhalten bleibt Wird vor der ersten Ebene wiederhergestellt und bleibt durch Zwischenstufen und die zweite Ebene verfügbar. Wird nach erfolgreicher zweiter Ebene gespeichert und vor Anwendungstransformationen entfernt. Ja, über dieselbe Authentifizierungsmethode, solange die Sitzung des Benutzers gültig ist.
_impersonate: Eine für Impersonation vorbereitete Zielidentität Transformationen der Authentifizierungsmethode und Extended UI, bis die Impersonation nach den Transformationen der zweiten Ebene abgeschlossen ist. Bereiten Sie das Target in jedem Anmeldeablauf erneut vor.

Beispielsweise kann _local:customer_found die nächste Aufgabe derselben Liste steuern, _internal:customer_category später von einer Anwendungstransformation gelesen werden und _session:profileId ein ausgewähltes Profil für die nächste Anwendungsanmeldung erhalten.

Transformationen zur Erstellung eines verknüpften externen Benutzers arbeiten mit den für diesen Schritt ausgewählten Claims und den aktuellen _session: Claims. Wählen Sie einen _internal: Claim als Eingabe aus, wenn diese Transformationen seinen Wert benötigen. Sitzungsclaims bleiben Teil des Authentifizierungsablaufs und werden nicht im externen Benutzerkonto gespeichert.

Transformationen wie Constant, Map, Match claim und Match claim and value können diese Claims über ihre normalen Aktionen erstellen oder verwenden. Das Präfix steuert die Lebensdauer. Verwenden Sie _session: an der Authentifizierungsmethode: Sitzungsclaims aus Anwendungstransformationen werden nicht in der Sitzung der Authentifizierungsmethode gespeichert.

Einen Wert in eine andere Lebensdauer kopieren

Eine Map Transformation kopiert einen Wert in den ausgewählten Ausgabeclaim. Quelle und Ziel sind getrennte Claims mit der Lebensdauer ihres jeweiligen Präfixes. Bei unterschiedlichen Namen ersetzt Replace claim vorhandene Werte des Zielclaims und behält den Quellclaim bei. Spätere Änderungen an einem Claim aktualisieren den anderen nicht automatisch.

Wenn etwa eine Query internal user Aufgabe _local:internal_user_id zurückgibt, fügen Sie im selben Satz eine Map Transformation von _local:internal_user_id nach _internal:selected_user_id hinzu. Spätere Sätze können _internal:selected_user_id lesen, nachdem der lokale Claim entfernt wurde. Ebenso kann eine Transformation der Authentifizierungsmethode einen _internal: Wert in einen _session: Claim kopieren, um ihn für spätere Anmeldungen zu erhalten.

Einen Sitzungswert an Anwendungstransformationen weitergeben

Angenommen, _session:profileId enthält customer-456, und Anwendungstransformationen benötigen diesen Wert. Konfigurieren Sie die folgende Transformation in der Liste der zweiten Ebene der Authentifizierungsmethode, nach allen Transformationen, die das ausgewählte Profil ändern:

Einstellung Wert
Transformationstyp Map
Aktion Replace claim
Eingabeclaim _session:profileId
Ausgabeclaim _internal:profileId

Der weitere Ablauf ist:

  1. Beide Claims enthalten für die verbleibenden Transformationen der Authentifizierungsmethode customer-456.
  2. Nach Abschluss der zweiten Ebene speichert FoxIDs _session:profileId für spätere Anmeldungen und entfernt ihn aus der aktuellen Claim-Sammlung.
  3. _internal:profileId gelangt zu den Anwendungstransformationen. Dort kann er Entscheidungen steuern, ohne an die Anwendung ausgestellt zu werden.
  4. Benötigt die Anwendung den Wert in ihrem Token oder ihrer Assertion, fügen Sie dort eine Map Transformation von _internal:profileId zu einem gewöhnlichen Claim wie profile_id hinzu und konfigurieren dessen Ausstellung.

Bei der nächsten Anwendungsanmeldung stellt FoxIDs _session:profileId für denselben authentifizierten Benutzer wieder her. Die Transformation der Authentifizierungsmethode erstellt für diesen Ablauf einen neuen _internal:profileId. Dasselbe Verfahren gilt bei der Übersetzung zwischen JWT und SAML Claims durch FoxIDs.

Weitergabe, Protokollmapping und externe APIs

Interne Claims und Sitzungsclaims benötigen keinen Eintrag in Forward claims; die allgemeinen Längenbegrenzungen gelten weiterhin. Reservierte Claim-Namen bleiben beim JWT/SAML Protokollmapping einschließlich automatischem Mapping unverändert. Verwenden Sie eine Map Claim-Transformation, um Werte zwischen Präfixen zu kopieren; Protokollmappings können keine reservierten Claim-Typen erstellen.

Keiner der drei reservierten Namensräume wird in Tokens oder Assertions ausgestellt, auch nicht mit * in Issue claims. Sie werden außerdem aus Anfragen und Antworten der externen Claims-API ausgeschlossen. Mappen Sie einen ausgewählten Wert vor dem API-Aufruf auf einen gewöhnlichen Claim und bei Bedarf anschließend einen gewöhnlichen Antwortclaim auf einen reservierten Claim.

Die Präfixe unterscheiden Groß- und Kleinschreibung und sind für FoxIDs reserviert. Reservierte Claims aus einem Protokoll oder einer Integrations-API werden vor den Transformationen entfernt. Auf bestehenden Benutzern gespeicherte reservierte Claims werden ignoriert; Claim-Aufgaben können sie nicht auf internen oder externen Benutzern speichern. Startet eine Aufgabe eine andere Authentifizierungsmethode, wird die aktuelle Claim-Sammlung nicht in den neuen Anmeldeablauf übertragen.

Sitzungsclaims

Mit _session: Claims speichern Sie kleine Zustandsmengen für denselben authentifizierten Benutzer über Browseranmeldungen bei verschiedenen Anwendungen hinweg. Sitzungen müssen an der Authentifizierungsmethode aktiviert sein; dies ist die Standardeinstellung. FoxIDs unterstützt Sitzungsclaims für die Authentifizierungsmethoden Login, External Login, OpenID Connect, SAML 2.0, WS-Federation und Environment Link.

FoxIDs stellt gespeicherte Sitzungsclaims vor den Transformationen der ersten Ebene bereit. Sie bleiben durch zwischenliegende Transformationen, Extended UI und die zweite Ebene verfügbar. Nach erfolgreichem Abschluss speichert FoxIDs die resultierenden Sitzungsclaims. Das Entfernen eines Sitzungsclaims in einer Transformation entfernt auch seinen gespeicherten Wert. Um einen gespeicherten Sitzungswert in Anwendungstransformationen zu verwenden, kopieren Sie ihn in einen internen Claim, bevor die Authentifizierungsmethode abgeschlossen wird.

Sitzungsclaims gehören zum ursprünglich authentifizierten Benutzer, unabhängig von Änderungen an sub durch Transformationen. Sie werden nur bei übereinstimmendem authentifiziertem Subject und einer gültigen, aktiven Sitzung derselben Authentifizierungsmethode wiederhergestellt. Akzeptiert die Methode mehrere Issuer, müssen die empfangenen Subjects über diese Issuer hinweg eindeutig sein. Eine Aufgabe zum Starten einer Authentifizierung überträgt Sitzungsclaims nicht auf eine andere Methode; reine Token-Abläufe lesen oder speichern keine Browser-Sitzungsclaims.

Login und External Login können ihre Browsersitzung wiederverwenden. Externe protokollbasierte Authentifizierungsmethoden authentifizieren weiterhin bei jeder Anwendungsanmeldung beim externen Identitätsanbieter. FoxIDs stellt die Sitzungsclaims nach Prüfung der zurückgegebenen Identität wieder her. Sitzungsclaims folgen der Sitzungslebensdauer der Authentifizierungsmethode und stehen nach Abmeldung oder Widerruf der Sitzung nicht mehr zur Verfügung.

Wenn eine neue Anmeldung denselben Benutzer verifiziert, während seine vorherige Sitzung noch gültig ist, behält FoxIDs die gespeicherten Werte dieser Sitzung während der Claim-Transformationen und Extended UI bei, bis die Transformationen der zweiten Ebene erfolgreich abgeschlossen sind und sie ersetzen. Eine abgeschlossene neue Anmeldung startet die absolute Sitzungslebensdauer der Authentifizierungsmethode neu; bei der Wiederverwendung einer Sitzung von Login oder External Login gelten deren konfigurierte gleitende und absolute Lebensdauer.

Login und External Login behalten die ursprünglichen Claims in der Browsersitzung bei, bevor Claim-Transformationen ausgeführt werden. Nach erfolgreichem Abschluss der Transformationen der zweiten Ebene aktualisiert FoxIDs die Sitzungsclaims für den authentifizierten Benutzer, auch nach Extended UI. Dabei bleiben die gewöhnlichen Claims und die Ablaufzeit der Sitzung erhalten. Jede Authentifizierungsmethode verwaltet im Browser einen aktuellen Benutzer und eine Sammlung von Sitzungsclaims. Eine neue Anmeldung folgt dem normalen Sitzungsverhalten der Authentifizierungsmethode; der Browser verwendet das zuletzt empfangene Sitzungscookie.

Für Sitzungsclaims gelten folgende Speichergrenzen:

Grenze Wert
Claim-Name 100 Zeichen einschließlich _session:, mit einem gültigen JWT Claim-Namen und einem Namen nach dem Präfix, der nicht leer ist oder nur aus Leerraum besteht
Einzelwert 1.000 Zeichen
Anzahl der Claims 10 Name/Wert-Paare; jeder Wert eines mehrwertigen Claims zählt einzeln
Gesamtlänge der Werte 2.000 Zeichen

Claims mit ungültigen Namen oder leeren beziehungsweise ausschließlich aus Leerraum bestehenden Werten werden ausgelassen. Längere Werte werden gekürzt. Claims werden der Reihe nach berücksichtigt; die Speicherung endet, wenn der nächste gültige Claim die Anzahl oder die Gesamtlänge überschreiten würde. Die allgemeine Claim-Validierung während der Authentifizierung gilt weiterhin.

Eine Transformation der Authentifizierungsmethode kann beispielsweise eine Referenz auf ein autorisiertes Impersonation-Target in _session:impersonation_target_id speichern. Spätere Anwendungsanmeldungen über diese Methode können damit den Zielbenutzer laden und die Berechtigungen erneut prüfen. Das vollständige Beispiel finden Sie unter Impersonation.

External claims - API

Sie können Ihr eigenes API von FoxIDs über eine Claim Transformation aufrufen. Das API wird mit Claims aufgerufen und die vom API zurückgegebenen Claims können mit einer Add oder Replace Aktion hinzugefügt werden. Das API wird nur aufgerufen, wenn mindestens ein ausgewähltes Claim existiert. Sie können * verwenden, um alle Claims auszuwählen und an Ihr API zu senden.

Reservierte _local:, _internal:, _session: und _impersonate: Claims werden aus API-Anfragen und -Antworten ausgeschlossen. Mappen Sie einen ausgewählten reservierten Wert vor dem Aufruf auf einen gewöhnlichen Claim oder anschließend einen gewöhnlichen Antwortclaim auf einen reservierten Claim.

Geschützte Claims wie sid und auth_time werden aus API-Antworten entfernt. Die übrigen Claims der Antwort werden gemäß der konfigurierten Aktion verarbeitet.

Use case Szenarien:

  • Rufen Sie Ihr API aus einer Authentifizierungsmethode auf, jedes Mal wenn ein Benutzer entweder in FoxIDs oder bei einem externen identity provider authentifiziert wird. Sie können den Benutzer in Ihrer Datenbank finden und eine User ID und vielleicht eine Customer ID oder anderes Relevantes zurückgeben. Sie können den Benutzer auch in Ihrer Datenbank erstellen.
  • Rufen Sie Ihr API aus einer Anwendungsregistrierung mit der User ID (sub) auf und fragen Sie die Rollen des Benutzers in Ihrer Datenbank ab. Ihr API würde dann entweder eine leere Liste oder eine Liste von Role Claims oder möglicherweise eine komplexere Berechtigungsstruktur zurückgeben.

Claims aus API-Antworten in lokale Claims laden

Setzen Sie das optionale Target für External claims API, um die Antwort-Claims in nachfolgenden Prüfungen oder Transformationen zu verwenden. Wenn Target auf target gesetzt ist, wird ein Claim namens sub aus der API-Antwort zu _local:target:sub und role zu _local:target:role. Die API gibt gewöhnliche Claim-Namen zurück; FoxIDs fügt das lokale Präfix nach dem Filtern und Validieren der Antwort hinzu. Der vollständige lokale Claim-Name muss innerhalb der Grenze von 100 Zeichen liegen. Lassen Sie Target leer, um Antwort-Claims direkt in der aktuellen Claim-Sammlung hinzuzufügen oder zu ersetzen.

Mehrere API-Aufrufe und interne Benutzerabfragen können dasselbe Target befüllen. Add claim fügt die zurückgegebenen Werte hinzu. Replace claim ersetzt die zurückgegebenen Claim-Typen unter diesem Target und behält die übrigen bei. Eine leere Antwort lässt vorhandene Target-Claims unverändert.

Lokale Target-Claims sind innerhalb des aktuellen Transformationssatzes verfügbar. Ordnen Sie einen Wert wie _local:target:sub dem Claim _internal:selected_user_id zu, um ihn in späteren Sätzen zu verwenden.

API implementieren

Sie müssen ein einfaches API implementieren, das FoxIDs aufruft, wenn die Claim Transformation ausgeführt wird. Bitte schauen Sie sich den Sample Code an.

Das API hat eine Base URL und die Funktionalität ist in Ordner unterteilt. Derzeit wird nur der Ordner claims (Funktionalität) zur Anforderung einer Liste von Claims unterstützt.

Wenn die Base URL des API https://somewhere.org/myclaimsstore ist, lautet die URL für den Ordner claims https://somewhere.org/myclaimsstore/claims.

FoxIDs Cloud ruft Ihr API von der IP Adresse 57.128.60.142 auf. Die ausgehende IP Adresse kann sich ändern und weitere können im Laufe der Zeit hinzugefügt werden.

Request

Gesichert mit HTTP Basic auth: Benutzername external_claims, Passwort = konfiguriertes Secret.

Das API wird mit HTTP POST und einem JSON Body aufgerufen.

Dies ist ein Request JSON Body mit zwei Input Claims:

{
  "claims": [
    { "type": "sub", "value": "1b1ac05e-5937-4939-a49c-0e84a89662df" },
    { "type": "email", "value": "some@test.org" }
  ]
}

Response - Success

Bei Erfolg muss das API HTTP Status 200 zurückgeben und eine Liste von claims (die Liste kann leer sein).

FoxIDs ignoriert Claims, deren type oder value fehlt, null oder leer ist oder nur aus Leerraum besteht. Bei aktiviertem Meldungs-Trace enthält der Antwort-Trace die empfangenen Claims vor der Filterung. Lange Trace-Meldungen werden gekürzt.

Beispielsweise die sub des Benutzers (User ID / Username), Customer ID und Rollen:

{
    "claims": [
        { "type": "sub", "value": "somewhere/external-some@test.org" },
        { "type": "customer_id", "value": "1234abcd" },
        { "type": "role", "value": "admin_access" },
        { "type": "role", "value": "read_access" },
        { "type": "role", "value": "write_access" }
    ]
}

Response - Error

Das API muss HTTP Status 401 (Unauthorized) und einen error (required) zurückgeben, wenn Basic auth abgelehnt wird. Optional kann eine Fehlerbeschreibung in ErrorMessage hinzugefügt werden.

{
    "error": "invalid_api_id_secret",
    "ErrorMessage": "Invalid API ID or secret"
}

Wenn andere Fehler auftreten, sollte das API HTTP Status 500 oder einen anderen passenden Fehlercode zurückgeben. Es wird empfohlen, eine technische Fehlermeldung in ErrorMessage für Diagnosezwecke hinzuzufügen (sie wird nur geloggt und nie dem Endbenutzer angezeigt).

Fehlermeldungen vom API in ErrorMessage werden NICHT dem Benutzer angezeigt; sie werden nur geloggt.

API Sample

Das Sample ExternalClaimsApiSample zeigt, wie das API in ASP.NET Core implementiert wird.

Sie können diese Postman collection verwenden, um Ihr API mit Postman aufzurufen und zu testen.

Configure

Konfigurieren Sie FoxIDs so, dass Ihr API über eine Claim Transformation im FoxIDs Control Client aufgerufen wird.

  1. Navigieren Sie zum Abschnitt Claim Transform
  2. Klicken Sie Add claim transform
  3. Klicken Sie External claims API
  4. Wählen Sie Add claim oder Replace claim
  5. Fügen Sie die ausgewählten Claims z. B. sub in Select claims hinzu
  6. Fügen Sie die Base API URL ohne den Ordner claims in API URL hinzu
  7. Fügen Sie das API secret hinzu Configure an external claims API claims transformation
  8. Setzen Sie optional Target, um Antwort-Claims in lokale Claims zu laden
  9. Klicken Sie Update

Claim Transform Beispiele

name Claim in die zwei Claims given_name und family_name aufteilen

Die Transformation teilt den Wert im name Claim beim ersten Leerzeichen und fügt die given_name und family_name Claims hinzu, falls sie nicht bereits existieren. Wenn mehr als ein Leerzeichen im name Claim Wert enthalten ist, werden keine neuen given_name und family_name Claims hinzugefügt, da sie bereits existieren.

Verwenden Sie zwei Regex map Claim Transformationen.

Transform name to given_name and family_name

  • Den family_name Claim Wert mit Regex ^\S+\s(?<map>\S+)$ finden
  • Den given_name Claim Wert mit Regex ^(?<map>\S+)\s\S+$ finden

Standardmäßig hinzugefügten Authentifizierungsmethode Namen aus sub entfernen

Der Name der Authentifizierungsmethode wird standardmäßig dem sub Claim Wert als Prefix mit Pipe z. B. some-auth-method|my-external-user-id hinzugefügt.

Sie können ein Replace Claim auf dem sub Claim verwenden, um den standardmäßig hinzugefügten Prefix zu entfernen.

Die Transformation teilt den Wert im sub Claim und ersetzt das Claim mit einem neuen sub, das nur die ursprüngliche ID enthält.

Verwenden Sie eine Regex map Claim Transformation und wählen Sie die Replace claim Aktion.

Remove default added post authentication method name

Finden Sie die ID ohne den standardmäßig hinzugefügten post authentication method Namen mit Regex ^([^|]+)\|(?<map>.+)$

Sie können dasselbe in einer SAML 2.0 Authentifizierungsmethode mit dem Claim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (enthält den SAML 2.0 Authn Response NameID Wert) anstelle des sub Claims durchführen.

email mit _local:mfa:email vergleichen und amr hinzufügen

Das Beispiel wird in einer Authentifizierungsmethode ausgeführt, die als MFA-Element verwendet wird. Es vergleicht den zurückgegebenen Claim email der Methode mit _local:mfa:email des Login-Benutzers. Wenn die beiden E-Mail-Werte gleich sind und mit einem regulären Ausdruck übereinstimmen, wird der Claim amr mit dem Namen der Authentifizierungsmethode als Wert hinzugefügt (der Methodenname wird als amr-Wert konfiguriert).

Der Login-MFA-Ablauf verwendet den hinzugefügten Claim amr, um den erfolgreichen Abschluss des MFA-Elements zu validieren. Der zurückgegebene Claim email und andere Claims der Authentifizierungsmethode werden nicht mit den Claims der Login-Authentifizierungsmethode zusammengeführt.

Verwenden Sie eine Concatenate Claim Transformation gefolgt von einer Regex match Claim Transformation.

Email vergleichen und amr hinzufügen

  • Concatenate: Neuer Claim _local:compare_emails, Aktion Replace claim, concatenate claims email und _local:mfa:email, concatenate format string {0}|{1}.
  • Regex match: Neuer Claim amr, Aktion Replace claim, select claim _local:compare_emails, regex value match ^([^|]+)\|\1$, neuer Wert auf den Namen der Authentifizierungsmethode gesetzt (zum Beispiel 9fk5z3vg).

Impersonation

Verwenden Sie die Transformation Impersonation in einer Authentifizierungsmethode, um Claims für einen anderen Benutzer auszustellen und den ursprünglich authentifizierten Benutzer als Akteur beizubehalten. Sitzungen müssen für die Authentifizierungsmethode aktiviert sein; dies ist standardmäßig der Fall.

Laden Sie das Target mit Query internal user, einer externen Claims API oder beidem, wobei Target beispielsweise auf target gesetzt wird. Prüfen Sie die Berechtigung des authentifizierten Benutzers und alle erforderlichen Target-Claims, bevor Sie das Target mit einer Impersonation Transformation auswählen. Target ist erforderlich und hat im Control Client den Standardwert target. Ein Anforderungsparameter der Anwendung wählt ein Target aus; er erteilt keine Impersonation-Berechtigung.

Speichern Sie eine Referenz auf das ausgewählte Target in einem Sitzungsclaim, um die Abfrage bei späteren Anwendungsanmeldungen zu wiederholen. Die Referenz kann eine interne Benutzer-ID oder eine externe Profil-ID sein und muss nicht dem ausgestellten sub des Targets entsprechen. Das folgende Beispiel für einen internen Benutzer verwendet impersonation_target_id für den Anforderungsparameter und den Sitzungsclaim. Diese Beispielnamen passen Sie an Ihren Ablauf an.

Das ausgewählte Target muss genau einen eindeutigen, nicht leeren sub enthalten. Andernfalls wird die Transformation ohne Auswahl dieses Targets fortgesetzt. Die Abfrage eines deaktivierten internen Benutzers liefert keine Claims. Verwenden Sie eine bedingte Fehleraufgabe, wenn Ihre Richtlinie bei nicht auswählbarem Target die Ablehnung der Anmeldung verlangt.

Die Transformation bereitet _impersonate: Claims für den Abschluss nach erfolgreichen Transformationen der zweiten Ebene vor. Beispielsweise wird _local:target:sub zu _impersonate:sub und _local:target:_local:internal_user_id zu _impersonate:_local:internal_user_id. Diese Claims können auch mit gewöhnlichen Transformationen vorbereitet werden. Sie bleiben zwischen den Transformationssätzen der Authentifizierungsmethode und über Extended UI verfügbar.

Beim Abschluss ersetzt FoxIDs die gewöhnlichen Identitätsclaims des Benutzers durch die gewöhnlichen Claims des Targets, behält den verifizierten Authentifizierungskontext bei und fügt einen act Claim hinzu, dessen sub den ursprünglich authentifizierten Benutzer identifiziert. Dieses Akteur-Subject ist der FoxIDs sub des Benutzers, bevor die Impersonation seine Claims ersetzt. Anwendungstransformationen erhalten diese effektive Identität. Reservierte Hilfsclaims werden nicht an Anwendungen ausgestellt.

Interne Zielkonten

Wenn _impersonate:_local:internal_user_id vorhanden ist, prüft FoxIDs, ob der interne Benutzer existiert und aktiviert ist, einschließlich der geltenden Access Structure Richtlinie. Das Zielkonto wird neben dem ursprünglichen Konto mit der Sitzung und den Grants verknüpft. Ist der interne Zielbenutzer ungültig, nicht vorhanden oder deaktiviert, wird keine Impersonation durchgeführt.

Das Deaktivieren oder Löschen eines der verknüpften Konten widerruft die aktive Sitzung und die Refresh-Token-Grants. Der Entzug von Access Structure Zugriff und Prüfungen zeitlich begrenzter Mitgliedschaften gelten auch für das verknüpfte Target. Wird ein Target ausschließlich von einer API ohne interne Kontoverknüpfung geliefert, bestimmen die konfigurierte API und die Transformationen bei jeder Anmeldung dessen Verfügbarkeit.

Beispiel: einen internen Benutzer impersonieren

Dieses Beispiel ermöglicht einem Mitarbeiter mit dem Claim-Wert allow_impersonation in role, einen internen Benutzer auszuwählen und bei späteren Anwendungsanmeldungen weiterhin als dieser Benutzer aufzutreten. Eine Anmeldung ohne ausgewähltes Target wird als ursprünglicher Benutzer fortgesetzt.

Das Diagramm folgt den acht unten konfigurierten Transformationen. Die Target-Referenz bleibt zwischen Anmeldungen erhalten; die Claims des Targets und die Berechtigung des Mitarbeiters werden bei jeder Anmeldung erneut geprüft.

Impersonierung eines internen Benutzers: Target auswählen, Berechtigung prüfen, Benutzer laden und Target-Referenz für spätere Anmeldungen speichern

Konfigurieren Sie impersonation_target_id unter Allowed request parameters jeder Anwendungsregistrierung, die den Parameter sendet. Die Anwendung übergibt eine interne Benutzer-ID als Parameterwert, den FoxIDs als _local:params:impersonation_target_id verfügbar macht. Siehe Anforderungsparameter von Anwendungen. Stellen Sie sicher, dass die Claims des Mitarbeiters role=allow_impersonation enthalten.

Fügen Sie der Liste Second-level claim transforms der Login Authentifizierungsmethode die folgenden acht Einträge in dieser Reihenfolge hinzu.

  1. Map: gespeicherte Target-Referenz wiederherstellen. Verwenden Sie Replace claim, setzen Sie Select claim auf _session:impersonation_target_id und New claim auf _local:impersonation_target_id.

  2. Map: Target aus der Anwendung übernehmen. Verwenden Sie Replace claim, setzen Sie Select claim auf _local:params:impersonation_target_id und New claim auf _local:impersonation_target_id. Ein übergebener Parameter ersetzt die gespeicherte Auswahl. Fehlt er, bleibt der Wert aus Schritt 1 erhalten.

  3. Match claim and value: Rolle des Mitarbeiters prüfen. Verwenden Sie Replace claim, setzen Sie Select claim auf role, Match value auf allow_impersonation, New claim auf _local:impersonation_check_passed und New value auf true.

  4. Match claim: Anmeldung ohne Target erlauben. Verwenden Sie Replace claim, if not match, setzen Sie Select claim auf _local:impersonation_target_id, New claim auf _local:impersonation_check_passed und New value auf true.

Der lokale Prüfclaim bedeutet, dass die Anmeldung fortgesetzt werden darf: Entweder besitzt der Mitarbeiter die erforderliche Rolle oder es wurde kein Target ausgewählt. Die Rollenprüfung erfolgt, bevor das Target die Claims des ursprünglichen Benutzers ersetzt.

Claim-Transformationen der zweiten Ebene 1–4: Target auswählen und Rolle des ursprünglichen Benutzers prüfen

  1. Match claim and return error: unberechtigte Auswahl ablehnen. Verwenden Sie If not match und wählen Sie _local:impersonation_check_passed. Setzen Sie Error auf access_denied und Error message auf You are not allowed to impersonate another user.

  2. Query internal user: Target laden. Verwenden Sie Replace claim, setzen Sie Lookup claim auf _local:impersonation_target_id, Lookup claim on internal user auf sub, Claims from internal user auf * und Target auf target. Die Abfrage gleicht die interne Benutzer-ID ab und lädt die Benutzerclaims einschließlich weitergeleiteter Access Structure Claims und lokaler Hilfsclaims unter _local:target:. Beispielsweise liefert sie _local:target:sub und _local:target:_local:internal_user_id.

  3. Impersonation: geladenes Target auswählen. Verwenden Sie Replace claim und setzen Sie Target auf target.

  4. Map: Target für spätere Anmeldungen speichern. Verwenden Sie Replace claim, setzen Sie Select claim auf _local:target:_local:internal_user_id und New claim auf _session:impersonation_target_id. Damit wird die stabile ID des geladenen Benutzers als Referenz für die nächste Anmeldung gespeichert.

Claim-Transformationen der zweiten Ebene 5–8: unberechtigte Auswahl ablehnen, internen Benutzer laden und impersonieren sowie Target-Referenz speichern

Falls Ihre Richtlinie einschränkt, welche Benutzer impersoniert werden dürfen, fügen Sie die Target-Prüfungen zwischen Schritt 6 und 7 ein. Prüfen Sie beispielsweise _local:target:role oder den Access Structure Hilfsclaim _local:target:_local:access_node.

Liefert die Abfrage kein Target, enden diese acht Schritte ohne Impersonation und behalten eine zuvor gespeicherte Target-Referenz bei. Fügen Sie nach der Abfrage eine bedingte Fehleraufgabe hinzu, wenn ein nicht verfügbares Target die Anmeldung ablehnen soll, oder entfernen Sie den Sitzungsclaim ausdrücklich, wenn die gespeicherte Auswahl gelöscht werden soll.

Impersonation fortsetzen und ändern

Jede Anwendungsanmeldung führt die Transformationen der Authentifizierungsmethode erneut aus. Im obigen Beispiel lesen sie die Target-Referenz aus _session:impersonation_target_id, wenn _local:params:impersonation_target_id fehlt, laden die aktuellen Target-Claims und wiederholen die Berechtigungsprüfungen vor der Auswahl der Impersonation. Die gespeicherte Referenz bleibt an den ursprünglich authentifizierten Benutzer und dieselbe Authentifizierungsmethode gebunden.

Um ein anderes Target auszuwählen, übergeben Sie eine neue Referenz im Anforderungsparameter und ersetzen den Sitzungsclaim, nachdem das neue Target die Prüfungen bestanden hat. Zum Beenden der Impersonation löschen Sie die gespeicherte Referenz und schließen die Transformationen ohne gültiges Impersonation-Target ab.

Ein erfolgreicher Abschluss mit demselben Target behält dessen sid bei. Die Auswahl eines anderen Targets, der Start einer Impersonation oder ein Abschluss ohne gültiges Target erzeugt eine neue sid und widerruft die vorherige aktive Sitzung und die Refresh-Token-Grants.

UserInfo und die Einlösung von Grants lehnen eine widerrufene aktive Sitzung ab. Anwendungen und APIs, die Tokens lokal validieren, müssen weiterhin ihre eigenen Regeln für Sitzungen und Token-Lebensdauern anwenden. SAML Single Logout verwendet die für jede Anwendung gespeicherten Ausstellungswerte.

Aktive Sitzungen und Refresh-Token-Grants zeigen das impersonierte Subject und den ursprünglichen Akteur im Control Client und in der Control API. Login-Auditereignisse enthalten den Akteur. Separate Impersonation-Auditereignisse protokollieren Start, Änderung und Ende einschließlich vorheriger und aktueller Sitzungs-IDs.