VerifyJWS-Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Richtliniensymbol

Was

Verifiziert die Signatur auf einer JWS, die von Clients oder anderen Systemen empfangen wurde. Diese Richtlinie extrahiert auch Header 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.

Wenn die JWS überprüft wurde und gültig ist, kann die Anfrage fortgesetzt werden. Wenn die JWS-Signatur nicht überprüft werden kann oder wenn die JWS aufgrund eines bestimmten Fehlers ungültig ist, wird die gesamte Verarbeitung beendet und in der Antwort wird ein Fehler zurückgegeben.

Diese Richtlinie ist eine erweiterbare Richtlinie und die Verwendung dieser Richtlinie kann je nach Apigee-Lizenz Auswirkungen auf die Kosten oder die Nutzung haben. Informationen zu Richtlinientypen und Auswirkungen auf die Nutzung finden Sie unter Richtlinientypen.

Informationen zu den Teilen einer JWS und deren Verschlüsselung und Signatur finden Sie unter RFC7515.

Video

In einem kurzen Video erfahren Sie, wie Sie die Signatur auf einer JWS überprüfen können. Dieses Video ist speziell für die Überprüfung eines JWT vorgesehen, viele der Konzepte sind jedoch für JWS identisch.

Beispiele

Angehängte JWS mit dem HS256-Algorithmus signieren überprüfen

Diese Beispielrichtlinie verifiziert eine angehängte JWS, die mit dem HS256-Verschlüsselungsalgorithmus HMAC mit einem SHA-256-Prüfsumme signiert wurde. Die JWS wird in der Proxyanfrage mit einem Formularparameter namens JWS übergeben. Der Schlüssel ist in einer Variablen mit dem Namen private.secretkey enthalten.

Ein angefügtes JWS enthält den codierten Header, die Nutzlast und die Signatur:

header.payload.signature

Die Richtlinienkonfiguration enthält die Informationen, die Apigee benötigt, um die JWS zu decodieren und zu bewerten, z. B. wo die JWS (in einer Ablaufvariable, die im Element <Source> angegeben ist) zu finden ist, den erforderlichen Signaturalgorithmus und wo der geheime Schlüssel zu finden ist, der in einer Apigee-Ablaufvariablen gespeichert ist, die beispielsweise von der Apigee KVM abgerufen werden kann.

<VerifyJWS name="JWS-Verify-HS256">
    <DisplayName>JWS Verify HS256</DisplayName>
    <Algorithm>HS256</Algorithm>
    <Source>request.formparam.JWS</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <SecretKey>
        <Value ref="private.secretkey"/>
    </SecretKey>
</VerifyJWS>

Die Richtlinie schreibt ihre Ausgabe in Kontextvariablen, damit nachfolgende Richtlinien oder Bedingungen im API-Proxy diese Werte prüfen können. Eine Liste der durch diese Richtlinie festgelegten Variablen finden Sie unter Ablaufvariablen.

Separates JWS, das mit dem RS256-Algorithmus signiert wurde

Diese Beispielrichtlinie verifiziert eine getrennte JWS, die mit dem RS256-Algorithmus signiert wurde. Zur Überprüfung müssen Sie den öffentlichen Schlüssel angeben. Die JWS wird in der Proxyanfrage mithilfe eines Formularparameters mit dem Namen JWS übergeben. Der öffentliche Schlüssel ist in einer Variablen mit dem Namen public.publickey enthalten.

Eine getrennte JWS lässt die Nutzlast der JWS aus:

header..signature

Sie können die Nutzlast an die VerifyJWS-Richtlinie übergeben. Dazu geben Sie den Variablennamen, der die Nutzlast enthält, an das Element <DetachedContent> an. Der angegebene Inhalt in <DetachedContent> muss im ursprünglichen nicht codierten Format angegeben werden, als es die JWS-Signatur erstellt hat.

<VerifyJWS name="JWS-Verify-RS256">
    <DisplayName>JWS Verify RS256</DisplayName>
    <Algorithm>RS256</Algorithm>
    <Source>request.formparam.JWS</Source>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PublicKey>
        <Value ref="public.publickey"/>
    </PublicKey>
    <DetachedContent>private.payload</DetachedContent>
</VerifyJWS>

Die Richtlinie schreibt ihre Ausgabe in Kontextvariablen, damit nachfolgende Richtlinien oder Bedingungen im API-Proxy diese Werte prüfen können. Eine Liste der durch diese Richtlinie festgelegten Variablen finden Sie unter Ablaufvariablen.

Schlüsselelemente festlegen

Welche Elemente Sie verwenden, um den Schlüssel zur Überprüfung des JWS anzugeben, hängt vom ausgewählten Algorithmus ab, wie in der folgenden Tabelle dargestellt:

Algorithmus Schlüsselelemente
HS* 
<SecretKey>
  <Value ref="private.secretkey"/>
</SecretKey>
RS*, ES*, PS* 
<PublicKey>
  <Value ref="rsa_public_key"/>
</PublicKey>

oder:

<PublicKey>
  <JWKS ref="jwks_val_ref_or_url"/>
</PublicKey>
* 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 JWS beschrieben.

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

S

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

<VerifyJWS name="JWS" continueOnError="false" enabled="true" async="false">

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

Attribut Beschreibung Standard Präsenz
Name Der interne Name der Richtlinie. Folgende Zeichen sind im Namen zulässig: A-Z0-9._\-$ %. Die Apigee-Benutzeroberfläche erzwingt jedoch zusätzliche Einschränkungen, z. B. das automatische Entfernen nicht alphanumerischer Zeichen.

Optional können Sie das Element <displayname></displayname> verwenden, um die Richtlinie im Proxy-Editor der Apigee-Benutzeroberfläche mit einem anderen Namen in der natürlichen Sprache zu versehen.

 – Erforderlich
continueOnError Legen Sie false fest, um einen Fehler zurückzugeben, wenn eine Richtlinie fehlschlägt. Dies ist für die meisten Richtlinien das erwartete Verhalten.

Legen Sie true fest, damit die Ablaufausführung auch nach dem Fehlschlagen einer Richtlinie fortgesetzt wird.

 false Optional
aktiviert Legen Sie true fest, um die Richtlinie zu erzwingen.

Legen Sie false fest, um die Richtlinie zu "deaktivieren". Die Richtlinie wird nicht erzwungen, selbst wenn sie mit einem Ablauf verknüpft ist.

 true Optional
async Dieses Attribut wurde verworfen. false Verworfen

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

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

Standard Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs der Richtlinie verwendet.
Präsenz Optional
Typ String

<Algorithm>

<Algorithm>HS256</Algorithm>

Gibt den Verschlüsselungsalgorithmus zum Signieren des Tokens an. 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.

Standard –
Präsenz Erforderlich
Typ String mit kommagetrennten Werten
Zulässige Werte HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512

<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 JWS-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 JWS-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.

Standard –
Präsenz Optional
Typ

String (Standard), Zahl, boolescher Wert oder Map.

Der Typ wird standardmäßig auf "String" gesetzt, wenn kein Typ angegeben ist.
Array Mit true wird angegeben, ob der Wert ein Typarray ist. Standardeinstellung: false
Zulässige Werte Jeder Wert, den Sie für eine zusätzliche Anforderung verwenden möchten.

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.

<DetachedContent>

<DetachedContent>variable-name-here</DetachedContent>

Eine generierte JWS mit einer Inhaltsnutzlast hat folgendes Format:

header.payload.signature

Wenn Sie die GenerateJWS-Richtlinie zum Erstellen einer getrennten Nutzlast verwenden, wird die Nutzlast im generierten JWS weggelassen. Sie hat das folgende Format:

header..signature

Bei einer getrennten Nutzlast müssen Sie die Nutzlast mithilfe des <DetachedContent> - Elements an die VerifyJWS-Richtlinie übergeben. Die angegebene Inhaltsnutzlast muss in der ursprünglichen, nicht codierten Form angegeben werden, die sie hatte, als die JWS-Signatur erstellt wurde.

Die Richtlinie gibt einen Fehler aus, wenn:

  • <DetachedContent> wird angegeben, wenn die JWS keine getrennte Inhaltsnutzlast enthält (Fehlercode steps.jws.ContentIsNotDetached).
  • <DetachedContent> wird weggelassen und die JWS hat eine getrennte Inhaltsnutzlast (Fehlercode ist steps.jws.InvalidSignature).
Standard N/A
Präsenz Optional
Typ Variablenreferenz

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

Auf "false" setzen, wenn die Richtlinie einen Fehler ausgibt, wenn ein im crit-Header des JWS nicht im <KnownHeaders>-Element aufgelistet ist. Setzen Sie den Wert auf "true", damit die VerifyJWS-Richtlinie den Header crit ignoriert.

Ein Grund dafür, dass dieses Element auf "true" gesetzt wird, ist, wenn Sie sich in einer Testumgebung befinden und wenn die Richtlinie aufgrund eines fehlenden Headers nicht ausgeführt werden soll.

Standard false
Präsenz Optional
Typ Boolesch
Zulässige Werte "true" oder "false"

<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).

Standard false
Präsenz Optional
Typ Boolesch
Zulässige Werte "true" oder "false"

<KnownHeaders>

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

or:

<KnownHeaders ref=’variable_containing_headers’/>

Die GenerateJWS-Richtlinie verwendet das Element <CriticalHeaders>, um den crit-Header in einen Token zu füllen. Beispiel:

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

Die VerifyJWS-Richtlinie prüft den Header crit in der JWS, sofern vorhanden, und für jedes aufgeführte Element prüft, ob das Element <KnownHeaders> auch diesen Header enthält. 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, aber nicht in der <KnownHeaders>-Liste aufgeführt ist, lässt die VerifyJWS-Richtlinie fehlschlagen.

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

Standard –
Präsenz Optional
Typ Kommagetrenntes Stringarray
Zulässige Werte Entweder ein Array oder der Name einer Variable, die das Array enthält.

<PublicKey/JWKS>

<!-- Specify the JWKS. -->
<PublicKey>
   <JWKS>jwks-value-here</JWKS>
</PublicKey>

or:

<!-- Specify a variable containing the JWKS. -->
<PublicKey>
   <JWKS ref="public.jwks"/>
</PublicKey>

or:

<!-- Specify a public URL that returns the JWKS.
The URL is static, meaning you cannot set it using a variable. -->
<PublicKey>
   <JWKS uri="jwks-url"/>
</PublicKey>

Gibt einen Wert im JWKS-Format (RFC 7517) an, das einen Satz öffentlicher Schlüssel enthält. Nur verwenden, wenn der Algorithmus einen der folgenden Werte hat: RS256/RS384/RS512, PS256/PS384/PS512 oder ES256/ES384/ES512.

Wenn die eingehende JWS eine Schlüssel-ID enthält, die im Satz von JWKS vorhanden ist, verwendet die Richtlinie den richtigen öffentlichen Schlüssel, um die JWS-Signatur zu überprüfen. Weitere Informationen zu dieser Funktion finden Sie unter JSON Web Key Set (JWKS) zur Überprüfung einer JWS 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.

Standard –
Präsenz Zum Prüfen einer JWS mithilfe eines RSA-Algorithmus müssen Sie entweder das JWKS- oder Wert-Element verwenden.
Typ String
Zulässige Werte Eine Ablaufvariable, ein Stringwert oder eine URL.

<PublicKey/Value>

<PublicKey>
   <Value ref="public.publickey"/>
</PublicKey>
-or-
<PublicKey>
    <Value>
    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAw2kPrRzcufvUNHvTH/WW
    Q0UrCw5c0+Y707KX3PpXkZGbtTT4nvU1jC0d1lHV8MfUyRXmpmnNxJHAC2F73IyN
    C5TBtXMORc+us7A2cTtC4gZV256bT4h3sIEMsDl0Joz9K9MPzVPFxa1i0RgNt06n
    Xn/Bs2UbbLlKP5Q1HPxewUDEh0gVMqz9wdIGwH1pPxKvd3NltYGfPsUQovlof3l2
    ALvO7i5Yrm96kknfFEWf1EjmCCKvz2vjVbBb6mp1ZpYfc9MOTZVpQcXSbzb/BWUo
    ZmkDb/DRW5onclGzxQITBFP3S6JXd4LNESJcTp705ec1cQ9Wp2Kl+nKrKyv1E5Xx
    DQIDAQAB
    -----END PUBLIC KEY-----
    </Value>
</PublicKey>

Gibt den öffentlichen Schlüssel an, mit dem die Signatur auf dem JWS überprüft wird. Verwenden Sie das ref-Attribut, um den Schlüssel in einer Ablaufvariable zu übergeben, oder geben Sie den PEM-codierten Schlüssel direkt an. Nur verwenden, wenn der Algorithmus entweder RS256/RS384/RS512, PS256/PS384/PS512 oder ES256/ES384/ES512 ist.

Standard –
Präsenz Zum Prüfen einer JWS, die mit einem RSA-Algorithmus signiert ist, müssen Sie entweder das JWKS- oder den Wertelemente verwenden.
Typ String
Zulässige Werte Eine Ablaufvariable oder ein String.

<SecretKey>

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

Gibt den geheimen Schlüssel an, der beim Verifizieren einer JWS verwendet werden soll, die einen symmetrischen Algorithmus (HS*) verwendet, entweder HS256, HS384 oder HS512.

Dieses Element ist optional. Sie müssen jedoch genau eines der Elemente <PublicKey> oder <SecretKey> angeben. Verwenden Sie das <PublicKey>-Element bei der Überprüfung einer JWS, für die der Algorithmus RS*, PS* oder ES* ist, und verwenden Sie das <SecretKey>-Element beim Prüfen einer JWS, für die der Algorithmus HS* ist.

Kinder von <SecretKey>

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

Kind Präsenz Beschreibung
encoding (Attribut) Optional

Gibt an, wie der Schlüssel in der referenzierten Variable codiert ist. Wenn kein encoding-Attribut vorhanden ist, wird die Codierung des Schlüssels standardmäßig als UTF-8 behandelt. Gültige Werte für das Attribut sind: „hex“, „base16“, „base64“ und „base64url“. Die Codierungswerte „hex“ und „base16“ sind synonym.

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

Da im obigen Beispiel die Codierung base64 lautet, wird der Schlüssel als Satz von 9 Byte decodiert, wenn die Variable private.secretkey den Inhalt SUxvdmVBUElz hat. Im hex-Format ist das 49 4c 6f 76 65 41 50 49 73.

Value (Element) Erforderlich

Einen codierten geheimen Schlüssel Gibt den geheimen Schlüssel an, mit dem die Nutzlast überprüft wird. Verwenden Sie das Attribut ref, um den Schlüssel indirekt über eine Variable wie private.secret-key bereitzustellen .

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

Apigee erzwingt eine Mindestschlüsselstärke für die Algorithmen HS256/HS384/HS512. Die Mindestschlüssellänge für HS256 beträgt 32 Byte, für HS384 48 Byte und für HS512 64 Byte. Die Verwendung eines Schlüssels mit geringerer Stärke führt zu einem Laufzeitfehler.

<Source>

<Source>JWS-variable</Source>

Wenn dieses Flag angegeben ist, wird die Ablaufvariable angegeben, in der die Richtlinie die zu suchende JWS erwartet.

Standard request.header.authorization (Wichtige Informationen zur Standardeinstellung finden Sie im Hinweis oben).
Präsenz Optional
Typ String
Zulässige Werte Ein Apigee-Ablaufvariablenname.

<Type>

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

Optionales Element, dessen einziger Wert Signed ist und angibt, dass die Richtlinie ein signiertes JWS überprüft. <Type> wird nur bereitgestellt, um mit dem entsprechenden Element für die GenerateJWT- und VerifyJWT-Richtlinien abzugleichen. Dabei kann es einen der Werte Signed oder Encrypted haben.

Standard –
Präsenz Optional
Typ String
Gültiger Wert Signed

Ablaufvariablen

Bei Erfolg legen die Richtlinien VerifyJWS und DecodeJWS Kontextvariablen gemäß diesem Muster fest:

jws.{policy_name}.{variable_name}

Beispiel: Lautet der Richtlinienname verify-jws, so speichert die Richtlinie den im JWS angegebene Algorithmus in dieser Kontextvariable: jws.verify-jws.header.algorithm

Variablenname Beschreibung
decoded.header.name JSON-Parsingwert eines Headers in der Nutzlast. Für jeden Header in der Nutzlast wird eine Variable festgelegt. Sie können auch die header.name-Ablaufvariablen verwenden. Dies ist jedoch die empfohlene Variable für den Zugriff auf einen Header.
header.algorithm Der für das JWS verwendete Signaturalgorithmus. Zum Beispiel RS256, HS384 usw. Weitere Informationen finden Sie unter Headerparameter (Algorithmus).
header.kid Die Schlüssel-ID, falls bei der Erstellung das JWS hinzugefügt. Weitere Informationen zur Verifizierung eines JWS finden Sie unter JSON-Webschlüsselsatz (JWKS) verwenden" in JWT und JWS-Richtlinien. Weitere Informationen finden Sie unter Header-Parameter (Key ID).
header.type Wert des Header-Typs. Weitere Informationen finden Sie unter (Type) Header-Parameter.
header.name Der Wert des benannten Headers (Standard oder Zusätzlich). Eines der Elemente wird für jeden zusätzlichen Header im Header-Teil des JWS bestimmt.
header-json Die Kopfzeile im JSON-Format.
payload Die JWS-Nutzlast, wenn dem JWS eine Nutzlast zugewiesen ist. Bei einer getrennten Nutzlast ist diese Variable leer.
valid Im Fall von VerifyJWS ist diese Variable "true", wenn die Signatur verifiziert wurde und die aktuelle Zeit vor Ablauf des Tokens bzw. nach dem Token-Wert "notBefore" liegt, sofern vorhanden. Andernfalls ist sie "false".

Im Fall von DecodeJWS ist die Variable nicht festgelegt.

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.

Fehlercode HTTP-Status Tritt auf, wenn Folgendes eintritt
steps.jws.AlgorithmInTokenNotPresentInConfiguration 401 Tritt auf, wenn die Prüfungsrichtlinie mehrere Algorithmen nutzt.
steps.jws.AlgorithmMismatch 401 Der im Header durch die Richtlinie Generate angegebene Algorithmus stimmte nicht mit dem in der Richtlinie Verify erwarteten überein. Die angegebenen Algorithmen müssen übereinstimmen.
steps.jws.ContentIsNotDetached 401 <DetachedContent> wird angegeben, wenn das JWS keine getrennte Inhaltsnutzlast enthält.
steps.jws.FailedToDecode 401 Die JWS konnte aufgrund der Richtlinie nicht entschlüsselt werden. Die JWS ist möglicherweise beschädigt.
steps.jws.InsufficientKeyLength 401 Für Schlüssel mit weniger als 32 Byte für den HS256-Algorithmus
steps.jws.InvalidClaim 401 Bei fehlendem Anspruch, nicht übereinstimmender Anforderung oder fehlendem oder nicht übereinstimmendem Header.
steps.jws.InvalidCurve 401 Die vom Schlüssel angegebene Kurve ist für den Elliptic-Curve-Algorithmus ungültig.
steps.jws.InvalidJsonFormat 401 Ungültige JSON-Datei im JWS-Header
steps.jws.InvalidJws 401 Dieser Fehler tritt auf, wenn die JWS-Signaturprüfung fehlschlägt.
steps.jws.InvalidPayload 401 Die JWS-Nutzlast ist ungültig.
steps.jws.InvalidSignature 401 <DetachedContent> wird weggelassen und das JWS hat eine separate Inhaltsnutzlast.
steps.jws.KeyIdMissing 401 Die Verify-Richtlinie verwendet einen JWKS als Quelle für öffentliche Schlüssel, aber das signierte JWS hat kein kid-Attribut im Header.
steps.jws.KeyParsingFailed 401 Der öffentliche Schlüssel konnte anhand der angegebenen Schlüsselinformationen nicht geparst werden.
steps.jws.MissingPayload 401 Die JWS-Nutzlast fehlt.
steps.jws.NoAlgorithmFoundInHeader 401 Tritt auf, wenn der JWS den Algorithmusheader weglässt.
steps.jws.NoMatchingPublicKey 401 Die Verify-Richtlinie verwendet einen JWKS als Quelle für öffentliche Schlüssel, aber der kid im signierten JWS ist nicht in JWKS aufgeführt.
steps.jws.UnhandledCriticalHeader 401 Ein Header, der von der JWS-Richtlinie im Header crit gefunden wurde, ist nicht in KnownHeaders aufgeführt.
steps.jws.UnknownException 401 Es ist eine unbekannte Ausnahme aufgetreten.
steps.jws.WrongKeyType 401 Falscher Schlüsseltyp angegeben. Wenn Sie beispielsweise einen RSA-Schlüssel für einen Elliptic Curve-Algorithmus oder einen Kurvenschlüssel für einen RSA-Algorithmus angeben.

Bereitstellungsfehler

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

Fehlername Tritt auf, wenn Folgendes eintritt
InvalidAlgorithm Die einzigen gültigen Werte sind RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512.

EmptyElementForKeyConfiguration

FailedToResolveVariable

InvalidConfigurationForActionAndAlgorithmFamily

InvalidConfigurationForVerify

InvalidEmptyElement

InvalidFamiliesForAlgorithm

InvalidKeyConfiguration

InvalidNameForAdditionalClaim

InvalidNameForAdditionalHeader

InvalidPublicKeyId

InvalidPublicKeyValue

InvalidSecretInConfig

InvalidTypeForAdditionalClaim

InvalidTypeForAdditionalHeader

InvalidValueForElement

InvalidValueOfArrayAttribute

InvalidVariableNameForSecret

MissingConfigurationElement

MissingElementForKeyConfiguration

MissingNameForAdditionalClaim

MissingNameForAdditionalHeader

 Andere mögliche Bereitstellungsfehler.

Fehlervariablen

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

Variablen Wo Beispiel
fault.name="fault_name" fault_name ist der Name des Fehlers, der in der obigen Tabelle Laufzeitfehler aufgeführt ist. Der Fehlername ist der letzte Teil des Fehlercodes. fault.name Matches "TokenExpired"
JWS.failed Bei allen JWT-Richtlinien wird im Fall eines Fehlers dieselbe Variable festgelegt. jws.JWS-Policy.failed = true

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="JWS Policy Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "TokenExpired")</Condition>
        </Step>
        <Condition>JWS.failed=true</Condition>
    </FaultRule>
</FaultRules>