Claims

Claims werden zuerst in der Authentifizierungsmethode und dann in der Anwendungsregistrierung verarbeitet. Dort kann entschieden werden, welche Claims an den nächsten Schritt weitergegeben werden, und es können Claim Transforms und Claim Tasks ausgeführt werden.

Alle Claim Vergleiche sind case sensitive.

Der Claim Prozess startet in der Authentifizierungsmethode, wenn ein Benutzer authentifiziert. Dort können Claim Transforms und Claim Tasks ausgeführt und festgelegt werden, welche Claims an den nächsten Schritt weitergegeben werden. Danach wird der Claim Prozess in der Anwendungsregistrierung fortgesetzt, wo ebenfalls Claim Transforms ausgeführt und konfiguriert werden kann, welche Claims an die Anwendung / API ausgegeben werden.

In einem Client Credentials Grant Szenario findet der Claim Prozess nur in der Anwendungsregistrierung statt. Gleiches gilt für Claim Transforms und die Konfiguration der Claims, die an die Anwendung / API ausgegeben werden.

Für innerhalb von FoxIDs verwendete Werte wählen Sie _local: für einen Transformationssatz, _internal: für den aktuellen Authentifizierungsablauf einschließlich Anwendungstransformationen oder _session: für spätere Browseranmeldungen über dieselbe Authentifizierungsmethode. Diese reservierten Claims werden nicht an Anwendungen ausgestellt. Unter Lokale, interne und Sitzungsclaims erfahren Sie auch, wie Sie einen Sitzungswert für Anwendungstransformationen in einen internen Claim kopieren.

Authentication method

In einer OpenID Connect und einer SAML 2.0 Authentifizierungsmethode werden Claims weitergegeben, indem sie der Liste Forward claims hinzugefügt werden. Alle Claims werden weitergegeben, wenn ein Wildcard * zur Liste Forward claims hinzugefügt wird.

Die folgenden Claims kennzeichnen die zuletzt verwendete Authentifizierungsmethode. Sie werden standardmäßig weitergeleitet und können in der Anwendungsregistrierung gelesen und in Claim Transforms und Claim Tasks verwendet werden:

  • auth_method enthält den Namen der Authentifizierungsmethode, der innerhalb der Umgebung eindeutig ist.
  • auth_method_type enthält den Typ der Authentifizierungsmethode: login, oidc, oauth2, saml2, wsfed, env_link oder ext_login.
  • auth_profile_method enthält den Namen des ausgewählten Profils der Authentifizierungsmethode. Dieser Claim ist enthalten, wenn ein Profil verwendet wird.

Ein sub Claim und Tokens, die von einem externen Identity Provider empfangen wurden, werden mit einem Pipe Zeichen (|) nach dem Namen der Authentifizierungsmethode verschachtelt. Beispiele:

  • Ein externer sub mit dem Wert afeda2a3-c08b-4bbb-ab77-35138dd2ef2d erhält den verschachtelten Wert the-auth-method|afeda2a3-c08b-4bbb-ab77-35138dd2ef2d
  • Ein externes Access Token mit dem Wert eyJhG.cRwczov...nNjb3B.lIjoi wird in den access_token Claim mit dem verschachtelten Wert the-auth-method|eyJhG.cRwczov...nNjb3B.lIjoi eingefügt
  • Wenn der externe OpenID Provider ein Refresh Token zurückgibt, kann es im refresh_token Claim mit dem verschachtelten Wert the-auth-method|refresh-token-value weitergeleitet werden

Application registration

In einer OpenID Connect, OAuth 2.0 und SAML 2.0 Anwendungsregistrierung werden Claims an die Anwendung / API ausgegeben, indem sie der Liste Issue claims hinzugefügt werden. Alle Claims werden an die Anwendung / API ausgegeben, wenn ein Wildcard * zur Liste Issue claims hinzugefügt wird.

Eine OpenID Connect Anwendungsregistrierung kann unterscheiden, ob ein Claim nur im Access Token oder auch im ID Token ausgegeben wird.

Eine OpenID Connect und OAuth 2.0 Anwendungsregistrierung kann Claims auch über einen Scope weitergeben. Dies geschieht, indem der Claim oder die Claims zur Liste Voluntary claims eines Scopes hinzugefügt werden. Die Claims werden dann ausgegeben, wenn die Client Anwendung den Scope anfordert. Eine OpenID Connect Anwendungsregistrierung kann auch bei freiwilligen Scope Claims unterscheiden, ob ein Claim nur im Access Token oder auch im ID Token ausgegeben wird.

Claim-Werttypen

JWT Claim-Werttypen einschließlich JSON-Objekten, Arrays, booleschen Werten und Zahlen bleiben erhalten, wenn Claims durch eine Map Transformation kopiert oder über Sitzungen, Extended UI und OAuth Grants weitergegeben werden. OpenID Connect UserInfo gibt diese Werte mit den entsprechenden JSON-Typen zurück.

Transformationen, die neuen Text erzeugen, etwa Regex-Mapping und Verkettung, erzeugen Zeichenfolgenwerte.

JWT/SAML Claim-Mapping bewahrt Werttypen wie boolesche Werte und Zahlen. Beim Mapping von JWT zu SAML werden JSON-Werte als Text in Zeichenfolgenattributen übertragen. Beim Mapping von SAML zu JWT werden Zeichenfolgen mit gültigen JSON-Objekten oder Arrays zu JSON-Claims.

Impersonierte Identitäten

Eine Authentifizierungsmethode kann mit einer Impersonation Transformation einen anderen Benutzer auswählen. Anwendungstransformationen erhalten dann die Claims des Zielbenutzers und einen act Claim, der den ursprünglich authentifizierten Benutzer identifiziert. _impersonate: Claims bereiten die Auswahl in den Transformationen der Authentifizierungsmethode vor; lokale Hilfsclaims behalten ihre reservierten Namen unter diesem Präfix.

In JWTs ist act ein JSON-Objekt, beispielsweise {"sub":"original-user"}. Sein standardmäßiges SAML-Mapping lautet http://schemas.foxids.com/ws/identity/claims/act und kann in den Claim-Mappings der Umgebung überschrieben werden. Wählen Sie den gemappten Claim unter Issue claims der SAML-Anwendung aus oder verwenden Sie *, um seinen JSON-Text auszustellen. Wird ein SAML-Attribut mit diesem JSON-Text zurück auf act gemappt, stellt FoxIDs es im JWT als JSON-Objekt aus.

Geschützte Claims

FoxIDs verwaltet Claims, die Sitzungen, die Gültigkeit von Tokens und das Routing zwischen Authentifizierungsmethoden steuern. Diese geschützten Claims können nicht als Ausgaben von Claim Transforms konfiguriert, in benutzerdefinierten JWT/SAML Claim Zuordnungen verwendet oder mit statischen Werten versehen werden.

Die geschützten JWT Claim Namen sind:

  • sid, iss, aud, exp, nbf, iat und auth_time.
  • client_id, azp, scope, nonce, at_hash und c_hash.
  • auth_method, auth_method_type, auth_profile_method und auth_method_issuer.

Die entsprechenden SAML Claim Typen für Sitzungsindex, Authentifizierungszeitpunkt, Client-ID und Authentifizierungsmethode sind ebenfalls geschützt. Die integrierten Protokollzuordnungen von FoxIDs bleiben verfügbar.

Transforms können geschützte Claims lesen und deren Werte in benutzerdefinierte Claims kopieren. Ein geschützter Claim kann auch ohne statische Werte in einer Liste der weiterzuleitenden oder auszugebenden Claims ausgewählt werden.

Dieselben Einschränkungen gelten für benutzerdefinierte Claims interner und externer Benutzer, anfängliche Claims des Mandantenbenutzers, Claims an Knoten der Zugriffsstruktur, Ausgabeclaims dynamischer UI-Elemente sowie statische Claims von Anwendungen und Scopes.

Geschützte Claims, die von einer Claims API, einer API zur Validierung von Extended UI, einer External Login API oder einer Directory Connector API zurückgegeben werden, werden verworfen. Vorhandene geschützte Claims im Ablauf bleiben erhalten. Ausgewählte geschützte Claims können als Eingabe an diese APIs gesendet werden.