VerifyJWT-Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Was

Verifiziert ein signiertes JWT oder entschlüsselt es und verifiziert ein verschlüsseltes JWT, das von Clients oder anderen Systemen empfangen wurde. Diese Richtlinie extrahiert auch die Anforderungen in Kontextvariablen, damit nachfolgende Richtlinien oder Bedingungen diese Werte untersuchen können, um Autorisierungs- oder Routingentscheidungen zu treffen. Eine detaillierte Einführung finden Sie unter Übersicht über JWS- und JWT-Richtlinien.

Diese Richtlinie ist eine Standardrichtlinie, die in jeder Umgebung bereitgestellt werden kann. Informationen zu Richtlinientypen und zur Verfügbarkeit bei jedem Umgebungstyp finden Sie unter Richtlinientypen.

Wenn diese Richtlinie ausgeführt wird, verifiziert Apigee im Fall eines signierten JWT die Signatur des JWT mithilfe des bereitgestellten Verifizierungsschlüssels. Im Fall eines verschlüsselten JWT entschlüsselt Apigee das JWT mithilfe des Entschlüsselungsschlüssels. In beiden Fällen überprüft Apigee anschließend, ob die JWT gemäß der Ablaufzeit und der Anfangszeit gültig ist, wenn sie vorhanden sind. Die Richtlinie kann optional auch die Werte bestimmter Anforderungen im JWT prüfen, z. B. Betreff, Aussteller, Zielgruppe oder Wert zusätzlicher Anforderungen.

Wenn das JWT verifiziert und gültig ist, werden alle darin enthaltenen Anforderungen in Kontextvariablen zur Verwendung durch nachfolgende Richtlinien oder Bedingungen extrahiert. Die Anfrage kann fortgesetzt werden. Wenn die JWT-Signatur nicht verifiziert werden kann oder das JWT aufgrund eines der Zeitstempel ungültig ist, wird die gesamte Verarbeitung beendet und ein Fehler wird in der Antwort zurückgegeben.

Informationen zu den Teilen eines JWT und deren Verschlüsselung und Signatur finden Sie unter RFC7519.

Wie

Ob die Richtlinie ein signiertes oder verschlüsseltes JWT verifiziert, hängt von dem Element ab, mit dem Sie den Algorithmus angeben, der das JWT überprüft:

• Wenn Sie das Element <Algorithm> verwenden, überprüft die Richtlinie ein signiertes JWT.
• Wenn Sie das Element <Algorithms> verwenden, überprüft die Richtlinie ein verschlüsseltes JWT.

Video

In einem kurzen Video erfahren Sie, wie Sie die Signatur auf einem JWT verifizieren.

Signiertes JWT überprüfen

In diesem Abschnitt wird erläutert, wie Sie ein signiertes JWT verifizieren. Verwenden Sie bei einem signierten JWT das Element <Algorithm>, um den Algorithmus zum Signieren des Schlüssels anzugeben.

Beispiele für ein signiertes JWT

In den folgenden Beispielen wird gezeigt, wie Sie ein signiertes JWT verifizieren.

<VerifyJWT name="JWT-Verify-HS256">
    <DisplayName>JWT Verify HS256</DisplayName>
    <Algorithm>HS256</Algorithm>
    <Source>request.formparam.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <SecretKey encoding="base64">
        <Value ref="private.secretkey"/>
    </SecretKey>
    <Subject>monty-pythons-flying-circus</Subject>
    <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
    <Audience>fans</Audience>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
</VerifyJWT>

<VerifyJWT name="JWT-Verify-RS256">
    <Algorithm>RS256</Algorithm>
    <Source>request.formparam.jwt</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PublicKey>
        <Value ref="public.publickey"/>
    </PublicKey>
    <Subject>apigee-seattle-hatrack-montage</Subject>
    <Issuer>urn://apigee-edge-JWT-policy-test</Issuer>
    <Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience>
    <AdditionalClaims>
        <Claim name="show">And now for something completely different.</Claim>
    </AdditionalClaims>
</VerifyJWT>

{
  "typ" : "JWT",
  "alg" : "RS256"
}

{
  "sub" : "apigee-seattle-hatrack-montage",
  "iss" : "urn://apigee-edge-JWT-policy-test",
  "aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
  "show": "And now for something completely different."
}

{
  "sub" : "monty-pythons-flying-circus",
  "iss" : "urn://apigee-edge-JWT-policy-test",
  "aud" : "urn://c60511c0-12a2-473c-80fd-42528eb65a6a",
  "show": "And now for something completely different."
}

In den obigen Beispielen wird das Element <Algorithm> verwendet, sodass ein signiertes JWT verifiziert wird. Das <PrivateKey>-Element gibt den Schlüssel an, der zum Signieren des JWT verwendet wird. Es gibt noch weitere Schlüsselelemente. Welche davon Sie verwenden, hängt vom Algorithmus ab, der durch den Wert von <Algorithm> angegeben wird, wie im nächsten Abschnitt beschrieben.

Schlüsselelemente für die Überprüfung eines signierten JWT festlegen

Mit den folgenden Elementen wird der Schlüssel angegeben, der zum Überprüfen eines signierten JWT verwendet wird:

• <SecretKey>
• <PublicKey>

Welches Element Sie verwenden, hängt vom ausgewählten Algorithmus ab, wie in der folgenden Tabelle dargestellt:

<SecretKey encoding="base16|hex|base64|base64url">
  <Value ref="private.secretkey"/>
</SecretKey>

<PublicKey>
  <Value ref="rsa_public_key_or_value"/>
</PublicKey>

<PublicKey>
  <Certificate ref="signed_cert_val_ref"/>
</PublicKey>

<PublicKey>
  <JWKS ref="jwks_val_or_ref"/>
</PublicKey>

Verschlüsseltes JWT überprüfen

In diesem Abschnitt wird erläutert, wie Sie ein verschlüsseltes JWT verifizieren. Verwenden Sie für ein verschlüsseltes JWT das Element <Algorithms>, um die Algorithmen zum Signieren des Schlüssels und des Inhalts anzugeben.

Beispiel für ein verschlüsseltes JWT

Das folgende Beispiel zeigt, wie ein verschlüsseltes JWT überprüft wird, wobei <Type> auf Encrypted gesetzt ist. Dabei gilt:

• Der Schlüssel wird mit dem RSA-OAEP-256-Algorithmus verschlüsselt.
• Der Inhalt wird mit dem A128GCM-Algorithmus verschlüsselt.

<VerifyJWT name="vjwt-1">
  <Algorithms>
    <Key>RSA-OAEP-256</Key>
    <Content>A128GCM</Content>
  </Algorithms>
  <Type>Encrypted</Type> 
  <PrivateKey>
    <Value ref="private.rsa_privatekey"/>
  </PrivateKey>
  <Subject>subject@example.com</Subject>
  <Issuer>urn://apigee</Issuer>
  <AdditionalHeaders>
    <Claim name="moniker">Harvey</Claim>
  </AdditionalHeaders>
  <TimeAllowance>30s</TimeAllowance>
  <Source>input_var</Source>
</VerifyJWT>

Im obigen Beispiel wird das Element <Algorithms> verwendet, sodass ein verschlüsseltes JWT verifiziert wird. Das <PrivateKey>-Element gibt den Schlüssel an, der zum Entschlüsseln des JWT verwendet wird. Es gibt noch weitere Schlüsselelemente. Welche davon Sie verwenden, hängt vom Algorithmus ab, der durch den Wert von <Algorithms> angegeben wird, wie im nächsten Abschnitt beschrieben.

Schlüsselelemente für die Überprüfung eines verschlüsselten JWT festlegen

Mit den folgenden Elementen wird der Schlüssel angegeben, der zur Überprüfung eines verschlüsselten JWT verwendet wird:

• <PrivateKey>
• <SecretKey>
• <PasswordKey>
• <DirectKey>

Welches Element Sie verwenden, hängt vom ausgewählten Schlüsselverschlüsselungsalgorithmus ab, wie in der folgenden Tabelle dargestellt:

<PrivateKey>
  <Value ref="private.rsa_privatekey"/>
</PrivateKey>

<PrivateKey>
  <Value ref="private.ec_privatekey"/>
</PrivateKey>

<SecretKey encoding="base16|hex|base64|base64url">
  <Value ref="private.flow-variable-name-here"/>
</SecretKey>

<PasswordKey>
  <Value ref="private.password-key"/>
  <SaltLength>
  <PBKDF2Iterations>
</PasswordKey>

<DirectKey>
  <Value encoding="base16|hex|base64|base64url" ref="private.directkey"/>
</DirectKey>

Weitere Informationen zu den Schlüsselanforderungen finden Sie unter Signaturverschlüsselungsalgorithmen.

Elementverweis

In der Richtlinienreferenz werden die Elemente und Attribute der Richtlinie zum Verifizieren des JWT beschrieben.

Hinweis: Die Konfiguration variiert je nach verwendetem Verschlüsselungsalgorithmus. In den Beispielen finden Sie Beispiele für Konfigurationen von bestimmten Anwendungsfällen.

Attribute, die für das Element der obersten Ebene gelten

<VerifyJWT name="JWT" continueOnError="false" enabled="true" async="false">

Die folgenden Attribute gelten für alle übergeordneten Richtlinienelemente.

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

Wird zusätzlich zum Namensattribut verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.

<Algorithm>

<Algorithm>HS256</Algorithm>

Gibt den kryptografischen Algorithmus an, der zur Überprüfung des Tokens verwendet wird. Verwenden Sie das Element <Algorithm>, um ein signiertes JWT zu überprüfen.

RS*/PS*/ES*-Algorithmen verwenden ein Paar aus öffentlichem/geheimem Schlüssel und HS*-Algorithmen ein gemeinsames Secret. Weitere Informationen finden Sie unter Signaturen für die Signaturverschlüsselung.

Sie können mehrere durch Kommas getrennte Werte angeben. Zum Beispiel "HS256, HS512" oder "RS256, PS256". Sie können jedoch HS*-Algorithmen nicht mit anderen und ES*-Algorithmen nicht mit anderen kombinieren, da sie einen bestimmten Schlüsseltyp erfordern. Sie können RS * - und PS * -Algorithmen kombinieren.

<Algorithms>

<Algorithms>
    <Key>key-algorithm</Key>
    <Content>content-algorithm</Content>
</Algorithm>

Verwenden Sie das Element <Algorithms>, um ein verschlüsseltes JWT zu überprüfen. Mit diesem Element wird der kryptografische Algorithmus für die Schlüsselverschlüsselung angegeben, der beim Erstellen des verschlüsselten JWT verwendet worden sein muss. Außerdem wird der Algorithmus für die Inhaltsverschlüsselung angegeben.

Untergeordnete Elemente von <Algorithms>

Die folgende Tabelle enthält eine allgemeine Beschreibung der untergeordneten Elemente von <Algorithms>:

Die Überprüfung schlägt in folgenden Fällen fehl:

• Der Algorithmus, der im Attribut alg im Header des verschlüsselten JWT bestätigt ist, unterscheidet sich vom hier im Element <Key> angegebenen Schlüsselverschlüsselungsalgorithmus.
• Die Richtlinie gibt ein <Content>-Element an und der Algorithmus, der im Attribut enc im Header des verschlüsselten JWT bestätigt wird, unterscheidet sich von dem im <Content>-Element angegebenen Algorithmus.

So überprüfen Sie beispielsweise ein verschlüsseltes JWT und prüfen, ob der Schlüsselalgorithmus RSA-OAEP-256 und der Inhaltsalgorithmus A128GCM ist:

  <Algorithms>
    <Key>RSA-OAEP-256</Key>
    <Content>A128GCM</Content>
  </Algorithms>

Umgekehrt können Sie ein verschlüsseltes JWT prüfen und überprüfen, ob der Schlüsselalgorithmus RSA-OAEP-256 ist, und keine Einschränkung für den Inhaltsalgorithmus erzwingen:

  <Algorithms>
    <Key>RSA-OAEP-256</Key>
  </Algorithms>

Schlüsselverschlüsselungs-Algorithmen

In der folgenden Tabelle sind die verfügbaren Algorithmen für die Schlüsselverschlüsselung sowie der Schlüsseltyp aufgeführt, den Sie zur Überprüfung eines JWT mit diesem Schlüsselverschlüsselungsalgorithmus angeben müssen.

Unter Verschlüsseltes JWT überprüfen finden Sie ein Beispiel, in dem der Schlüsselverschlüsselungsalgorithmus RSA-OAEP-256 ist, sodass Sie das Element <PrivateKey> verwenden.

Algorithmen für die Inhaltsverschlüsselung

Für die VerifyJWT-Richtlinie müssen Sie keinen Algorithmus für die Inhaltsverschlüsselung angeben. Wenn Sie den Algorithmus für die Inhaltsverschlüsselung angeben möchten, können Sie dies mit dem untergeordneten <Content> des Elements <Algorithms> tun.

Unabhängig vom Schlüsselverschlüsselungsalgorithmus werden die folgenden Algorithmen – alle symmetrischen und AES-basierten – für die Inhaltsverschlüsselung unterstützt:

• A128CBC-HS256
• A192CBC-HS384
• A256CBC-HS512
• A128GCM
• A192GCM
• A256GCM

<Audience>

<Audience>audience-here</Audience>

or:

<Audience ref='variable-name-here'/>

Die Richtlinie überprüft, ob die Zielgruppenanforderung im JWT mit dem in der Konfiguration angegebenen Wert übereinstimmt. Wenn keine Übereinstimmung gefunden wird, gibt die Richtlinie einen Fehler aus. Mit dieser Anforderung werden die Empfänger identifiziert, für die das JWT bestimmt ist. Dies ist eine der in RFC7519 genannten registrierten Anforderungen.

<AdditionalClaims/Claim>

<AdditionalClaims>
    <Claim name='claim1'>explicit-value-of-claim-here</Claim>
    <Claim name='claim2' ref='variable-name-here'/>
    <Claim name='claim3' ref='variable-name-here' type='boolean'/>
</AdditionalClaims>

or:

<AdditionalClaims ref='claim_payload'/>

Validiert, dass die JWT-Nutzlast die angegebenen zusätzlichen Anforderungen enthält und die bestätigten Anforderungswerte übereinstimmen.

Eine zusätzliche Anforderung verwendet einen Namen, der nicht zu den standardmäßigen, registrierten JWT-Anforderungsnamen gehört. Der Wert einer zusätzlichen Anforderung kann ein String, eine Zahl, ein boolescher Wert, ein Map oder ein Array sein. Ein Map besteht aus einer Reihe von Name/Wert-Paaren. Der Wert für eine Anforderung dieser Typen kann explizit in der Richtlinienkonfiguration oder indirekt über einen Verweis auf eine Ablaufvariable angegeben werden.

Das Element <Claim> verwendet die folgenden Attribute:

• name – (erforderlich) Der Name der Anforderung.
• ref – (optional) Der Name einer Ablaufvariable. Falls vorhanden, verwendet die Richtlinie den Wert dieser Variable als Anforderung. Wenn sowohl ein ref-Attribut als auch ein expliziter Anforderungswert angegeben sind, ist der explizite Wert der Standardwert. Er wird verwendet, wenn die referenzierte Ablaufvariable nicht aufgelöst wird.
• type – (optional) Kann String (Standard), Zahl, boolescher Wert oder Map sein
• array – (optional) Legen Sie true fest, um anzugeben, dass der Wert ein Typarray ist. Standardeinstellung: false.

Wenn Sie das Element <Claim> hinzufügen, werden die Anforderungsnamen beim Konfigurieren der Richtlinie statisch festgelegt. Alternativ können Sie ein JSON-Objekt übergeben, um die Anforderungsnamen anzugeben. Da das JSON-Objekt als Variable übergeben wird, werden die Anforderungsnamen zur Laufzeit bestimmt.

Beispiele:

<AdditionalClaims ref='json_claims'/>

Die Variable json_claims enthält ein JSON-Objekt im folgenden Format:

{
  "sub" : "person@example.com",
  "iss" : "urn://secure-issuer@example.com",
  "non-registered-claim" : {
    "This-is-a-thing" : 817,
    "https://example.com/foobar" : { "p": 42, "q": false }
  }
}

<AdditionalHeaders/Claim>

<AdditionalHeaders>
    <Claim name='claim1'>explicit-value-of-claim-here</Claim>
    <Claim name='claim2' ref='variable-name-here'/>
    <Claim name='claim3' ref='variable-name-here' type='boolean'/>
    <Claim name='claim4' ref='variable-name' type='string' array='true'/>
</AdditionalHeaders>

Validiert, dass der JWT-Header die angegebenen zusätzlichen Name/Wert-Paare der Anforderung enthält und die Werte der bestätigten Anforderung übereinstimmen.

Eine zusätzliche Anforderung verwendet einen Namen, der nicht einem der standardmäßigen registrierten JWT-Anforderungsnamen entspricht. Der Wert einer zusätzlichen Anforderung kann ein String, eine Zahl, ein boolescher Wert, ein Map oder ein Array sein. Ein Map besteht aus einer Reihe von Name/Wert-Paaren. Der Wert für eine Anforderung dieser Typen kann explizit in der Richtlinienkonfiguration oder indirekt über einen Verweis auf eine Ablaufvariable angegeben werden.

Das Element <Claim> verwendet die folgenden Attribute:

• name – (erforderlich) Der Name der Anforderung.
• ref – (optional) Der Name einer Ablaufvariable. Falls vorhanden, verwendet die Richtlinie den Wert dieser Variable als Anforderung. Wenn sowohl ein ref-Attribut als auch ein expliziter Anforderungswert angegeben sind, ist der explizite Wert der Standardwert. Er wird verwendet, wenn die referenzierte Ablaufvariable nicht aufgelöst wird.
• type – (optional) Kann String (Standard), Zahl, boolescher Wert oder Map sein
• array – (optional) Legen Sie true fest, um anzugeben, dass der Wert ein Typarray ist. Standardeinstellung: false.

<CustomClaims>

Hinweis: Derzeit wird ein CustomClaims-Element eingefügt, wenn Sie eine neue GenerateJWT-Richtlinie über die UI hinzufügen. Dieses Element ist nicht funktionsfähig und wird ignoriert. Das richtige zu verwendende Element ist <AdditionalClaims>. Die Benutzeroberfläche wird aktualisiert, sodass später die richtigen Elemente eingefügt werden.

<Id>

<Id>explicit-jti-value-here</Id>
 -or-
<Id ref='variable-name-here'/>
 -or-
<Id/>

Überprüft, ob das JWT die bestimmte jti-Anforderung hat. Wenn der Textwert und das ref-Attribut beide leer sind, generiert die Richtlinie eine jti mit einer zufälligen UUID. Die Anforderung der JWT-ID (jti) ist eine eindeutige Kennung für das JWT. Weitere Informationen über jti finden Sie unter RFC7519.

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

Setzen Sie diesen Wert auf "false", wenn die Richtlinie einen Fehler ausgibt, wenn ein im crit-Header des JWT aufgeführter Header nicht im <KnownHeaders>-Element aufgelistet ist. Setzen Sie den Wert auf "true", damit die VerifyJWT-Richtlinie den Header crit ignoriert.

Ein Grund für die Festlegung auf "true" wäre, dass Sie sich in einer Testumgebung befinden und noch nicht bereit sind, einen Fehler durch einen fehlenden Header zu beheben.

<IgnoreIssuedAt>

<IgnoreIssuedAt>true|false</IgnoreIssuedAt>

Auf "false" (Standard) setzen, wenn die Richtlinie einen Fehler ausgeben soll, wenn ein JWT eine iat-Anforderung (ausgegeben am) enthält, die einen Zeitpunkt in der Zukunft angibt. Setzen Sie diesen Wert auf "true", damit die Richtlinie während der Verifizierung iat ignoriert.

<IgnoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

Setzen Sie diesen Wert auf "false", wenn die Richtlinie einen Fehler ausgibt, falls eine in der Richtlinie angegebene Variable, auf die verwiesen wird, nicht auflösbar ist. Setzen Sie diesen Wert auf "true", um alle nicht aufgelösten Variablen als leeren String zu behandeln (null).

<Issuer>

<VerifyJWT name='VJWT-29'>
  ...
  <!-- verify that the iss claim matches a hard-coded value -->
  <Issuer>issuer-string-here</Issuer>

  or:

  <!-- verify that the iss claim matches the value contained in a variable -->
  <Issuer ref='variable-containing-issuer'/>

  or:

  <!-- verify via a variable; fallback to a hard-coded value if the variable is empty -->
  <Issuer ref='variable-containing-issuer'>fallback-value-here</Issuer>

Die Richtlinie verifiziert, ob der Aussteller im JWT (die Anforderung iss) mit dem im Konfigurationselement angegebenen String übereinstimmt. Die iss-Anforderung ist eine der in IETF RFC 7519 genannten registrierten Ansprüche.

<KnownHeaders>

<KnownHeaders>a,b,c</KnownHeaders>

or:

<KnownHeaders ref='variable_containing_headers'/>

Die GenerateJWT-Richtlinie verwendet das Element <CriticalHeaders>, um den Header crit in einem JWT zu füllen. Beispiele:

{
  "typ": "...",
  "alg" : "...",
  "crit" : [ "a", "b", "c" ],
}

Die VerifyJWT-Richtlinie prüft den Header crit im JWT, sofern vorhanden, und prüft für jeden Header, ob dieser auch im <KnownHeaders>-Element aufgelistet ist. Das Element <KnownHeaders> kann eine Obermenge der in crit aufgelisteten Elemente enthalten. Es müssen nur die in crit aufgeführten Header im Element <KnownHeaders> aufgelistet sein. Jeder Header, den die Richtlinie in crit findet, der aber nicht in <KnownHeaders> aufgeführt ist, lässt die VerifyJWT-Richtlinie fehlschlagen.

Sie können die VerifyJWT-Richtlinie optional konfigurieren, um den Header crit zu ignorieren. Dazu setzen Sie das Element <IgnoreCriticalHeaders> auf true.

<MaxLifespan>

  <VerifyJWT name='VJWT-62'>
  ...
  <!-- hard-coded lifespan of 5 minutes -->
  <MaxLifespan>5m</MaxLifespan>

  or:

  <!-- refer to a variable -->
  <MaxLifespan ref='variable-here'/>

  or:

  <!-- attribute telling the policy to use iat rather than nbf -->
  <MaxLifespan useIssueTime='true'>1h</MaxLifespan>

  or:

  <!-- useIssueTime and ref, and hard-coded fallback value. -->
  <MaxLifespan useIssueTime='true' ref='variable-here'>1h</MaxLifespan>
  ...
  

Konfiguriert die VerifyJWT-Richtlinie, um zu prüfen, ob die Lebensdauer eines Tokens einen angegebenen Grenzwert nicht überschreitet. Sie können den Grenzwert mithilfe einer Zahl gefolgt von einem Zeichen angeben. Diese gibt die Anzahl der Sekunden, Minuten, Stunden, Tage oder Wochen an. Die folgenden Zeichen sind gültig:

• s - Sekunden
• m - Minuten
• h - Stunden
• d - Tage
• w - Wochen

Sie können beispielsweise einen der folgenden Werte angeben: 120s, 10m, 1h, 7d, 3w.

Die Richtlinie berechnet die tatsächliche Lebensdauer des Tokens durch Subtrahieren des alten Werts (nbf) vom Ablaufwert (exp). Wenn entweder exp oder nbf fehlt, gibt die Richtlinie einen Fehler aus. Wenn die Tokenlebensdauer die angegebene Zeitspanne überschreitet, gibt die Richtlinie einen Fehler aus.

Sie können das optionale Attribut useIssueTime auf true setzen, um den Wert iat anstelle des Werts nbf zu verwenden, wenn die Token-Lebensdauer berechnet wird.

Die Verwendung des Elements MaxLifespan ist optional. Wenn Sie dieses Element verwenden, können Sie es nur einmal verwenden.

<PrivateKey>

Verwenden Sie dieses Element, um den privaten Schlüssel anzugeben, mit dem ein JWT verifiziert werden kann, das mit einem asymmetrischen Algorithmus verschlüsselt wurde. Es folgt eine Beschreibung der möglichen untergeordneten Elemente.

<Password>

<PrivateKey>
  <Password ref="private.privatekey-password"/>
</PrivateKey>

Ein untergeordnetes Element des <PrivateKey>-Elements. Gibt das Passwort an, das die Richtlinie zum Entschlüsseln des privaten Schlüssels verwenden soll, wenn ein verschlüsseltes JWT überprüft wird. Verwenden Sie das Attribut ref, um das Passwort in einer Ablaufvariable zu übergeben.

<Value>

<PrivateKey>
  <Value ref="private.variable-name-here"/>
</PrivateKey>

Untergeordnet unter dem Element <PrivateKey>. Gibt einen PEM-codierten privaten Schlüssel an, mit dem die Richtlinie ein verschlüsseltes JWT prüft. Verwenden Sie das Attribut ref, um den Schlüssel in einer Ablaufvariable zu übergeben.

<PublicKey>

Gibt die Quelle für den öffentlichen Schlüssel an, der zum Verifizieren eines JWT verwendet wird, das mit einem asymmetrischen Algorithmus signiert wurde. Zu den Unterstützungsalgorithmen gehören RS256/RS384/RS512, PS256/PS384/PS512 oder ES256/ES384/ES512. Es folgt eine Beschreibung der möglichen untergeordneten Elemente.

<Certificate>

<PublicKey>
  <Certificate ref="signed_public.cert"/>
</PublicKey>

-or-

<PublicKey>
  <Certificate>
-----BEGIN CERTIFICATE-----
cert data
-----END CERTIFICATE-----
  </Certificate>
</PublicKey>

Ein untergeordnetes Element des <PublicKey>-Elements. Gibt das signierte Zertifikat an, das als Quelle des öffentlichen Schlüssels verwendet wird. Verwenden Sie das ref-Attribut, um das signierte Zertifikat in einer Ablaufvariablen zu übergeben, oder geben Sie das PEM-codierte Zertifikat direkt an.

<JWKS>

  <PublicKey>
    <JWKS …  > … </JWKS>
  </PublicKey>

Ein untergeordnetes Element des <PublicKey>-Elements. Gibt einen JWKS als Quelle öffentlicher Schlüssel an. Dies ist eine Liste der Schlüssel gemäß dem in IETF RFC 7517 – JSON Web Key (JWK) beschriebenen Format.

Wenn das eingehende JWT eine Schlüssel-ID besitzt, die im Satz von JWKS vorhanden ist, verwendet die Richtlinie den richtigen öffentlichen Schlüssel, um die JWT-Signatur zu verifizieren. Weitere Informationen zu diesem Feature finden Sie unter JSON Web Key Set (JWKS) zur Verifizierung eines JWT verwenden.

Wenn Sie den Wert von einer öffentlichen URL abrufen, speichert Apigee das JWKS für einen Zeitraum von 300 Sekunden im Cache. Wenn der Cache abläuft, ruft Apigee die JWKS-Datei noch einmal ab.

<Value>

<PublicKey>
  <Value ref="public.publickeyorcert"/>
</PublicKey>

-or-

<PublicKey>
  <Value>
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2kPrRzcufvUNHvTH/WW
...YOUR PUBLIC KEY MATERIAL HERE....d1lH8MfUyRXmpmnNxJHAC2F73IyN
ZmkDb/DRW5onclGzxQITBFP3S6JXd4LNESJcTp705ec1cQ9Wp2Kl+nKrKyv1E5Xx
DQIDAQAB
-----END PUBLIC KEY-----
  </Value>
</PublicKey>

Ein untergeordnetes Element des <PublicKey>-Elements. Gibt den öffentlichen Schlüssel an, der zum Verifizieren der Signatur auf einem signierten JWT verwendet werden soll. Verwenden Sie das ref-Attribut, um den Schlüssel in einer Ablaufvariable zu übergeben, oder geben Sie den PEM-codierten Schlüssel direkt an.

<RequiredClaims>

<VerifyJWT name='VJWT-1'>
  ...
  <!-- Directly specify the names of the claims to require -->
  <RequiredClaims>sub,iss,exp</RequiredClaims>

  -or-

  <!-- Specify the claim names indirectly, via a context variable -->
  <RequiredClaims ref='claims_to_require'/>
  ...
</VerifyJWT>

Das <RequiredClaims>-Element ist optional. Gibt eine durch Kommas getrennte Liste mit Namen von Anforderungen an, die bei der Verifizierung eines JWT in der JWT-Nutzlast vorhanden sein müssen. Das Element stellt sicher, dass das präsentierte JWT die erforderlichen Anforderungen enthält, validiert aber nicht den Inhalt der Anforderungen. Wenn eine der aufgelisteten Anforderungen nicht vorhanden ist, gibt die VerifyJWT-Richtlinie zur Laufzeit einen Fehler aus.

<SecretKey>

<SecretKey encoding="base16|hex|base64|base64url" >
  <Value ref="private.your-variable-name"/>
</SecretKey>
  

Das SecretKey-Element ist optional. Es gibt den geheimen Schlüssel an, der beim Überprüfen eines signierten JWT, das einen symmetrischen Algorithmus (HS*) verwendet, oder beim Überprüfen eines verschlüsselten JWT, das einen symmetrischen Algorithmus (AES) für die Schlüsselverschlüsselung verwendet, angegeben werden soll.

Untergeordnete Elemente von <SecretKey>

In der folgenden Tabelle sind die untergeordneten Elemente und Attribute von <SecretKey> beschrieben:

<SecretKey encoding="hex" >
  <Value ref="private.secretkey"/>
</SecretKey>

<SecretKey>
  <Value ref="private.my-secret-variable"/>
</SecretKey>

<Source>

<Source>jwt-variable</Source>

Gibt, sofern vorhanden, die Ablaufvariable an, in der die Richtlinie das zu verifizierende JWT findet.

Mit diesem Element können Sie die Richtlinie so konfigurieren, dass das JWT aus einer Formular- oder Abfrageparametervariablen oder einer anderen Variablen abgerufen wird. Wenn dieses Element vorhanden ist, entfernt die Richtlinie kein vorhandenes Bearer-Präfix. Wenn die Variable nicht vorhanden ist oder die Richtlinie kein JWT in der angegebenen Variable findet, gibt die Richtlinie einen Fehler zurück.

Wenn kein <Source>-Element vorhanden ist, ruft die Richtlinie standardmäßig das JWT ab. Dazu wird die Variable request.header.authorization gelesen und das Präfix Bearer wird entfernt. Wenn Sie das JWT im Autorisierungs-Header als Inhabertoken (mit dem Präfix Bearer) übergeben, geben Sie das Element <Source> in der Richtlinienkonfiguration nicht an. Sie würden beispielsweise kein <Source>-Element in der Richtlinienkonfiguration verwenden, wenn Sie das JWT im Autorisierungs-Header so übergeben:

curl -v https://api-endpoint/proxy1_basepath/api1 -H "Authorization: Bearer eyJhbGciOiJ..."

<Subject>

<VerifyJWT name='VJWT-8'>
  ...
  <!-- verify that the sub claim matches a hard-coded value -->
  <Subject>subject-string-here</Subject>

  or:

  <!-- verify that the sub claim matches the value contained in a variable -->
  <Subject ref='variable-containing-subject'/>

  or:

  <!-- verify via a variable; fallback to a hard-coded value if the variable is empty -->
  <Subject ref='variable-containing-subject'>fallback-value-here</Subject>

Die Richtlinie verifiziert, ob das Subjekt im JWT (die Anforderung sub) mit dem in der Richtlinienkonfiguration angegebenen String übereinstimmt. Die Anforderung sub ist eine der in RFC7519 beschriebenen registrierten Anforderungen.

<TimeAllowance>

<VerifyJWT name='VJWT-23'>
  ...
  <!-- configure a hard-coded time allowance of 20 seconds -->
  <TimeAllowance>20s</TimeAllowance>

  or:

  <!-- refer to a variable containing the time allowance -->
  <TimeAllowance ref='variable-containing-time-allowance'/>

  or:

  <!-- refer to a variable; fallback to a hard-coded value if the variable is empty -->
  <TimeAllowance ref='variable-containing-allowance'>30s</TimeAllowance>
  

Der "Kulanzzeitraum" für Zeiten, um die Zeitverzögerung zwischen dem Aussteller und dem Verifizierer eines JWT zu berücksichtigen. Dies gilt sowohl für den Ablauf (die Anforderung exp) als auch für den "Not-before-Time" (die Anforderung nbf). Beispiel: Wenn das Zeitlimit auf 30s festgelegt ist, wird ein abgelaufenes JWT nach dem bestätigten Ablauf für 30 Sekunden als noch gültig behandelt. Das "not-before-time" wird ähnlich ausgewertet.

<Type>

<Type>type-string-here</Type>

Beschreibt, ob die Richtlinie ein signiertes oder ein verschlüsseltes JWT verifiziert. Das <Type>-Element ist optional. Sie können damit Leser über die Konfiguration informieren, unabhängig davon, ob die Richtlinie ein signiertes oder ein verschlüsseltes JWT generiert.

• Wenn das Element <Type> vorhanden ist:
  • Wenn <Type> den Wert Signed hat, bestätigt die Richtlinie ein signiertes JWT und das Element <Algorithm> muss vorhanden sein.
  • Wenn <Type> den Wert Encrypted hat, bestätigt die Richtlinie ein verschlüsseltes JWT und das Element <Algorithms> muss vorhanden sein.
• Wenn das Element <Type> nicht vorhanden ist:
  • Wenn das Element <Algorithm> vorhanden ist, geht die Richtlinie davon aus, dass <Type> den Wert Signed hat.
  • Wenn das Element <Algorithms> vorhanden ist, geht die Richtlinie davon aus, dass <Type> den Wert Encrypted hat.
• Wenn weder <Algorithm> noch <Algorithms> vorhanden ist, ist die Konfiguration ungültig.

Ablaufvariablen

Bei Erfolg werden bestimmen die Richtlinien JWT prüfen und JWT dekodieren entsprechend folgendem Muster Kontextvariablen:

jwt.{policy_name}.{variable_name}

Beispiel: Lautet der Richtlinienname jwt-parse-token, so speichert die Richtlinie das im JWT angegebene Subjekt in dieser Kontextvariable: jwt.jwt-parse-token.decoded.claim.sub Aus Gründen der Abwärtskompatibilität ist es auch in jwt.jwt-parse-token.claim.subject verfügbar.

Fehlerreferenz

In diesem Abschnitt werden die zurückgegebenen Fehlercodes und Fehlermeldungen beschrieben, die von Apigee festgelegt werden, wenn die Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.

Laufzeitfehler

Diese Fehler können bei Ausführung der Richtlinie auftreten.

Bereitstellungsfehler

Diese Fehler können auftreten, wenn Sie einen Proxy mit dieser Richtlinie bereitstellen.

Fehlervariablen

Diese Variablen werden bei Laufzeitfehlern festgelegt. Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen.

Beispiel für eine Fehlerantwort

Bei der Fehlerbehandlung besteht die Best Practice darin, den errorcode-Teil der Fehlerantwort zu beachten. Verlassen Sie sich nicht auf den Text in faultstring. Er kann sich ändern.

Beispiel für eine Fehlerregel

    <FaultRules>
        <FaultRule name="JWT Policy Errors">
            <Step>
                <Name>JavaScript-1</Name>
                <Condition>(fault.name Matches "InvalidToken")</Condition>
            </Step>
            <Condition>JWT.failed=true</Condition>
        </FaultRule>
    </FaultRules>