<ph type="x-smartling-placeholder"></ph>
Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur
Apigee X-Dokumentation. Weitere Informationen

Was
Generiert ein signiertes JWT mit einem konfigurierbaren Satz von Anforderungen. Das JWT kann dann an Clients zurückgegeben, an Backend-Ziele übertragen oder auf andere Weise genutzt werden. Eine detaillierte Einführung finden Sie unter Übersicht über JWS- und JWT-Richtlinien.
Video
In diesem kurzen Video erfahren Sie, wie Sie ein signiertes JWT generieren.
Beispiele
- Ein mit dem HS256-Algorithmus signiertes JWT generieren
- Ein mit dem RS256-Algorithmus signiertes JWT generieren
Ein mit dem HS256-Algorithmus signiertes JWT generieren
Diese Beispielrichtlinie generiert ein neues JWT und signiert es unter Einsatz des HS256-Algorithmus. HS256 stützt sich auf ein gemeinsames Secret für die Signatur und die Verifizierung der Signatur.
Wenn diese Richtlinienaktion ausgelöst wird, codiert Edge den JWT-Header und die Nutzlast dann digital. signiert das JWT. Das Video oben zeigt ein umfassendes Beispiel, in dem auch beschrieben wird, wie Sie eine Anfrage an die Richtlinie senden.
Die Richtlinienkonfiguration erstellt in diesem Fall ein JWT mit einem Standardanforderungssatz, wie in der JWT-Spezifikation definiert, einschließlich einer Ablaufzeit von 1 Stunde sowie einer zusätzlichen Anforderung. Sie können beliebig viele zusätzliche Anforderungen hinzufügen. Details zu den Anforderungen und Optionen für die einzelnen Elemente in dieser Beispielrichtlinie finden Sie in der Elementreferenz.
<GenerateJWT name="JWT-Generate-HS256"> <DisplayName>JWT Generate HS256</DisplayName> <Algorithm>HS256</Algorithm> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <SecretKey> <Value ref="private.secretkey"/> <Id>1918290</Id> </SecretKey> <ExpiresIn>1h</ExpiresIn> <Subject>monty-pythons-flying-circus</Subject> <Issuer>urn://apigee-edge-JWT-policy-test</Issuer> <Audience>fans</Audience> <Id/> <AdditionalClaims> <Claim name="show">And now for something completely different.</Claim> </AdditionalClaims> <OutputVariable>jwt-variable</OutputVariable> </GenerateJWT>
Das resultierende JWT hat dann folgenden Header…
{ "typ" : "JWT", "alg" : "HS256", "kid" : "1918290" }
… und eine Nutzlast mit Inhalten wie diesem:
{ "sub" : "monty-pythons-flying-circus", "iss" : "urn://apigee-edge-JWT-policy-test", "aud" : "show", "iat" : 1506553019, "exp" : 1506556619, "jti" : "BD1FF263-3D25-4593-A685-5EC1326E1F37", "show": "And now for something completely different." }
Der Wert der Anforderungen iat, exp und jti variiert.
Ein mit dem RS256-Algorithmus signiertes JWT generieren
Diese Beispielrichtlinie generiert ein neues JWT und signiert es unter Einsatz des RS256-Algorithmus. Das Generieren einer RS256-Signatur benötigt einen privaten RSA-Schlüssel, der in PEM-codierter Form bereitgestellt werden muss. Das Video oben zeigt ein umfassendes Beispiel, in dem auch beschrieben wird, wie Sie eine Anfrage an die Richtlinie senden.
Wenn diese Richtlinienaktion ausgelöst wird, codiert und signiert Edge das JWT, einschließlich der Anforderungen, digital. Informationen zu den Teilen eines JWT und deren Verschlüsselung und Signatur finden Sie unter RFC7519.
<GenerateJWT name="JWT-Generate-RS256"> <Algorithm>RS256</Algorithm> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <PrivateKey> <Value ref="private.privatekey"/> <Password ref="private.privatekey-password"/> <Id ref="private.privatekey-id"/> </PrivateKey> <Subject>apigee-seattle-hatrack-montage</Subject> <Issuer>urn://apigee-edge-JWT-policy-test</Issuer> <Audience>urn://c60511c0-12a2-473c-80fd-42528eb65a6a</Audience> <ExpiresIn>60m</ExpiresIn> <Id/> <AdditionalClaims> <Claim name="show">And now for something completely different.</Claim> </AdditionalClaims> <OutputVariable>jwt-variable</OutputVariable> </GenerateJWT>
Schlüsselelemente festlegen
Welche Elemente Sie verwenden, um den Schlüssel zur Generierung der JWS anzugeben, hängt vom ausgewählten Algorithmus ab, wie in der folgenden Tabelle dargestellt:
Algorithmus | Schlüsselelemente | |
---|---|---|
HS{256/384/512}* | <SecretKey> <Value ref="private.secretkey"/> <Id>1918290</Id> </SecretKey> |
|
RS/PS/ES{256/384/512}* | <PrivateKey> <Value ref="private.privatekey"/> <Password ref="private.privatekey-password"/> <Id ref="private.privatekey-id"/> </PrivateKey> Die Elemente |
|
* Weitere Informationen zu den Schlüsselanforderungen finden Sie unter Signaturverschlüsselungsalgorithmen. |
Elementreferenz für das JWT generieren
Die Richtlinienreferenz beschreibt die Elemente und Attribute der Richtlinie zur JWT-Generierung.
Hinweis: Die Konfiguration variiert je nach verwendetem Verschlüsselungsalgorithmus. In den Beispielen finden Sie Beispiele für Konfigurationen von bestimmten Anwendungsfällen.
Attribute, die auf das oberste Element angewendet werden
<GenerateJWT name="JWT" 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 Edge-Management-Benutzeroberfläche erzwingt jedoch zusätzliche
Einschränkungen gelten, z. B. das automatische Entfernen von Zeichen, die nicht alphanumerisch sind.
Optional können Sie das Element |
– | 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 |
false | Optional |
Aktiviert | Legen Sie true fest, um die Richtlinie zu erzwingen.
Legen Sie |
true | Optional |
async | Dieses Attribut wurde verworfen. | false | Veraltet |
<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.
Standard | Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs der Richtlinie verwendet. |
Präsenz | Optional |
Typ | String |
<Algorithm>
<Algorithm>algorithm-here</Algorithm>
Gibt den Verschlüsselungsalgorithmus zum Signieren des Tokens an.
Default | – |
Präsenz | Erforderlich |
Typ | String |
Zulässige Werte | HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512 |
<Audience>
<Audience>audience-here</Audience> or: <Audience ref='variable_containing_audience'/>
Die Richtlinie generiert ein JWT, das eine aud-Anforderung mit dem angegebenen Wert enthält. Diese Anforderung identifiziert die Empfänger, für die das JWT bestimmt ist. Dies ist eine der in RFC7519 genannten registrierten Anforderungen.
Standard | – |
Präsenz | Optional |
Typ | Array (eine Liste mit durch Kommas getrennten Werten) |
Zulässige Werte | Alles, was die Zielgruppe identifiziert. |
<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'/>
Ermöglicht die Angabe zusätzlicher Name/Wert-Paare für Anforderungen in der Nutzlast des JWT. Sie können die Anforderung explizit als String, Zahl, booleschen Wert, Zuordnung oder Array angeben. Ein Map ist einfach eine Reihe von Name/Wert-Paaren.
Default | – |
Präsenz | Optional |
Zulässige Werte | Jeder Wert, den Sie für eine zusätzliche Anforderung verwenden möchten. Sie können die Anforderung explizit als String, Zahl, booleschen Wert, Zuordnung oder Array angeben. |
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 im generierten JWT zur Laufzeit bestimmt.
Beispiel:
<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 } } }
Das generierte JWT enthält alle Anforderungen im JSON-Objekt.
<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>
Fügt die zusätzlichen Paare aus Anforderungsname/Wert in den Header für die JWS ein.
Default | – |
Präsenz | Optional |
Zulässige Werte | Jeder Wert, den Sie für eine zusätzliche Anforderung verwenden möchten. Sie können die Anforderung explizit als String, Zahl, booleschen Wert, Zuordnung oder Array angeben. |
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.
<CriticalHeaders>
<CriticalHeaders>a,b,c</CriticalHeaders> or: <CriticalHeaders ref=’variable_containing_headers’/>
Fügt dem JWT-Header den kritischen Header crit hinzu. Der Header crit ist ein Array aus Headernamen, die bekannt sein und vom JWT-Empfänger erkannt werden müssen. Beispiel:
{ “typ: “...”, “alg” : “...”, “crit” : [ “a”, “b”, “c” ], }
Zur Laufzeit untersucht die VerifyJWT-Richtlinie den crit-Header.
Für jedes im crit-Header aufgeführte Element wird überprüft, ob das Element <KnownHeaders>
der VerifyJWT-Richtlinie auch diesen Header enthält. Jeder Header, den die Richtlinie in crit findet, aber nicht in der <KnownHeaders>
-Liste aufgeführt ist, lässt die VerifyJWT-Richtlinie fehlschlagen.
Standard | – |
Präsenz | Optional |
Typ | Kommagetrenntes Stringarray |
Zulässige Werte | Entweder ein Array oder der Name einer Variable, die das Array enthält. |
<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.
<ExpiresIn>
<ExpiresIn>time-value-here</ExpiresIn>
Gibt die Lebensdauer des JWT in Millisekunden, Sekunden, Minuten, Stunden oder Tagen an.
Standard | N/A |
Präsenz | Optional |
Typ | Ganzzahl |
Zulässige Werte |
Ein Wert oder ein Verweis auf eine Ablaufvariable, die den Wert enthält. Zeiteinheiten können so angegeben werden:
Beispiel: |
<Id>
<Id>explicit-jti-value-here</Id> -or- <Id ref='variable-name-here'/> -or- <Id/>
Generiert ein JWT mit der spezifischen jti-Anforderung. Wenn der Textwert und das ref-Attribut beide leer sind, generiert die Richtlinie einen 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.
Standard | – |
Präsenz | Optional |
Typ | String oder Verweis. |
Zulässige Werte | Ein String oder der Name einer Ablaufvariablen, die die ID enthält. |
<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 | Boolean |
Zulässige Werte | "true" oder "false" |
<Issuer>
<Issuer ref='variable-name-here'/> <Issuer>issuer-string-here</Issuer>
Die Richtlinie generiert ein JWT, das eine Anforderung mit dem Namen iss, mit einem auf den angegebenen Wert gesetzten Wert enthält. Eine Anforderung, die den Aussteller des JWT identifiziert. Dies ist eine der registrierten Anforderungen, die in RFC7519 erwähnt werden.
Standard | – |
Präsenz | Optional |
Typ | String oder Verweis |
Zulässige Werte | Alle |
<NotBefore>
<!-- Specify an absolute time. --> <NotBefore>2017-08-14T11:00:21-07:00</NotBefore> -or- <!-- Specify a time relative to when the token is generated. --> <NotBefore>6h</NotBefore>
Gibt die Uhrzeit an, zu der das Token gültig wird. Das Token ist bis zur angegebenen Zeit ungültig. Sie können entweder einen absoluten Zeitwert oder eine Zeit relativ zum Zeitpunkt der Generierung des Tokens angeben.
Standard | – |
Präsenz | Optional |
Typ | String |
Zulässige Werte | Siehe unten. |
Gültige Zeitwerte für das "NotBefore"-Element für absolute Zeitwerte
Name | Format | Beispiel |
sortierbar | yyyy-MM-dd'T'HH:mm:ss.SSSZ |
2017-08-14T11:00:21.269-0700 |
RFC 1123 | EEE, dd MMM yyyy HH:mm:ss zzz |
Mon, 14 Aug 2017 11:00:21 PDT |
RFC 850 | EEEE, dd-MMM-yy HH:mm:ss zzz |
Monday, 14-Aug-17 11:00:21 PDT |
ANCI-C | EEE MMM d HH:mm:ss yyyy |
Mon Aug 14 11:00:21 2017 |
Geben Sie für relative Zeitwerte eine Ganzzahl und einen Zeitraum an. Beispiel:
- 10s
- 60m
- 12h
<OutputVariable>
<OutputVariable>jwt-variable</OutputVariable>
Gibt an, wo das von dieser Richtlinie generierte JWS platziert werden soll. Standardmäßig wird es in die Ablaufvariable jwt.POLICYNAME.generated_jwt
eingefügt.
Standard | jwt.POLICYNAME.generated_jwt |
Präsenz | Optional |
Typ | String (Name einer Ablaufvariablen) |
<PrivateKey/Id>
<PrivateKey> <Id ref="flow-variable-name-here"/> </PrivateKey> or <PrivateKey> <Id>your-id-value-here</Id> </PrivateKey>
Gibt die Schlüssel-ID (Kid) an, die im JWT-Header enthalten sein muss. Nur verwenden, wenn der Algorithmus RS256/RS384/RS512, PS256/PS384/PS512 oder ES256/ES384/ES512 ist.
Standard | – |
Präsenz | Optional |
Typ | String |
Zulässige Werte | Eine Ablaufvariable oder ein String |
<PrivateKey/Password>
<PrivateKey> <Password ref="private.privatekey-password"/> </PrivateKey>
Falls erforderlich, geben Sie das Passwort an, das die Richtlinie zum Entschlüsseln des privaten Schlüssels verwenden soll. Verwenden Sie das Attribut ref, um den Schlüssel in einer Ablaufvariable zu übergeben. Nur verwenden, wenn der Algorithmus RS256/RS384/RS512, PS256/PS384/PS512 oder ES256/ES384/ES512 ist.
Standard | – |
Präsenz | Optional |
Typ | String |
Zulässige Werte | Eine Referenz für eine Ablaufvariable. Hinweis: Sie müssen eine Ablaufvariable angeben. Edge wird als ungültig abgelehnt
Richtlinienkonfiguration, bei der das Passwort als Klartext angegeben wird. Die Ablaufvariable muss das Präfix "private" haben. Beispiel: |
<PrivateKey/Value>
<PrivateKey> <Value ref="private.variable-name-here"/> </PrivateKey>
Gibt einen PEM-codierten privaten Schlüssel an, der zum Signieren des JWT verwendet wird. Verwenden Sie das Attribut ref, um den Schlüssel in einer Ablaufvariable zu übergeben. Nur verwenden, wenn der Algorithmus RS256/RS384/RS512, PS256/PS384/PS512 oder ES256/ES384/ES512 ist.
Standard | – |
Präsenz | Zum Generieren eines JWT mithilfe des RS256-Algorithmus erforderlich. |
Typ | String |
Zulässige Werte | Eine Ablaufvariable mit einem String, der einen privaten PEM-codierten RSA-Schlüsselwert darstellt. Hinweis: Die Ablaufvariable muss das Präfix "private" haben. Beispiel: |
<SecretKey/Id>
<SecretKey> <Id ref="flow-variable-name-here"/> </SecretKey> or <SecretKey> <Id>your-id-value-here</Id> </SecretKey>
Gibt die Schlüssel-ID (kid) an, die in den JWT-Header eines mit einem HMAC-Algorithmus signierten JWT einzufügen ist. Nur verwenden, wenn der folgenden Algorithmen verwendet wurde: HS256/HS384/HS512.
Standard | – |
Präsenz | Optional |
Typ | String |
Zulässige Werte | Eine Ablaufvariable oder ein String |
<SecretKey/Value>
<SecretKey> <Value ref="private.your-variable-name"/> </SecretKey>
Stellt den geheimen Schlüssel zum Verifizieren oder Signieren von Tokens mit einem HMAC-Algorithmus bereit. Nur verwenden, wenn der folgenden Algorithmen verwendet wurde: HS256/HS384/HS512 Verwenden Sie das Attribut ref, um den Schlüssel in einer Ablaufvariable zu übergeben.
Edge erzwingt eine Mindestschlüsselstärke für die HS256/HS384/HS512-Algorithmen. 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.
Standard | – |
Präsenz | Erforderlich für HMAC-Algorithmen. |
Typ | String |
Zulässige Werte | Eine Ablaufvariable, die auf einen String verweist. Hinweis: Wenn eine Ablaufvariable vorhanden ist, muss sie das Präfix "private" haben. Beispiel: |
<Subject>
<Subject>subject-string-here</Subject>
<Subject ref="flow_variable" />
Beispiel:
<Subject ref="apigee.developer.email"/>
Die Richtlinie generiert ein JWT mit einem sub-Anspruch, der auf den angegebenen Wert gesetzt ist. Mit diesem Anspruch wird eine Aussage über das Subjekt des JWT identifiziert oder gemacht. Dies ist einer der Standardansprüche, die in RFC7519 erwähnt werden.
Standard | – |
Präsenz | Optional |
Typ | String |
Zulässige Werte | Jeder Wert, der eindeutig ein auf einen Wert verweisendes Subjekt oder eine solche Ablaufvariable identifiziert. |
Ablaufvariablen
Die Richtlinie zum Generieren von JWTs legt keine Ablaufvariablen fest.
Fehlerreferenz
This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.
Runtime errors
These errors can occur when the policy executes.
Fault code | HTTP status | Occurs when |
---|---|---|
steps.jwt.AlgorithmInTokenNotPresentInConfiguration |
401 | Occurs when the verification policy has multiple algorithms. |
steps.jwt.AlgorithmMismatch |
401 | The algorithm specified in the Generate policy did not match the one expected in the Verify policy. The algorithms specified must match. |
steps.jwt.FailedToDecode |
401 | The policy was unable to decode the JWT. The JWT is possibly corrupted. |
steps.jwt.GenerationFailed |
401 | The policy was unable to generate the JWT. |
steps.jwt.InsufficientKeyLength |
401 | For a key less than 32 bytes for the HS256 algorithm, less than 48 bytes for the HS386 algortithm, and less than 64 bytes for the HS512 algorithm. |
steps.jwt.InvalidClaim |
401 | For a missing claim or claim mismatch, or a missing header or header mismatch. |
steps.jwt.InvalidCurve |
401 | The curve specified by the key is not valid for the Elliptic Curve algorithm. |
steps.jwt.InvalidJsonFormat |
401 | Invalid JSON found in the header or payload. |
steps.jwt.InvalidToken |
401 | This error occurs when the JWT signature verification fails. |
steps.jwt.JwtAudienceMismatch |
401 | The audience claim failed on token verification. |
steps.jwt.JwtIssuerMismatch |
401 | The issuer claim failed on token verification. |
steps.jwt.JwtSubjectMismatch |
401 | The subject claim failed on token verification. |
steps.jwt.KeyIdMissing |
401 | The Verify policy uses a JWKS as a source for public keys, but the signed JWT does not
include a kid property in the header. |
steps.jwt.KeyParsingFailed |
401 | The public key could not be parsed from the given key information. |
steps.jwt.NoAlgorithmFoundInHeader |
401 | Occurs when the JWT contains no algorithm header. |
steps.jwt.NoMatchingPublicKey |
401 | The Verify policy uses a JWKS as a source for public keys, but the kid
in the signed JWT is not listed in the JWKS. |
steps.jwt.SigningFailed |
401 | In GenerateJWT, for a key less than the minimum size for the HS384 or HS512 algorithms |
steps.jwt.TokenExpired |
401 | The policy attempts to verify an expired token. |
steps.jwt.TokenNotYetValid |
401 | The token is not yet valid. |
steps.jwt.UnhandledCriticalHeader |
401 | A header found by the Verify JWT policy in the crit header is not
listed in KnownHeaders . |
steps.jwt.UnknownException |
401 | An unknown exception occurred. |
steps.jwt.WrongKeyType |
401 | Wrong type of key specified. For example, if you specify an RSA key for an Elliptic Curve algorithm, or a curve key for an RSA algorithm. |
Deployment errors
These errors can occur when you deploy a proxy containing this policy.
Error name | Cause | Fix |
---|---|---|
InvalidNameForAdditionalClaim |
The deployment will fail if the claim used in the child element <Claim>
of the <AdditionalClaims> element is one of the following registered names:
kid , iss , sub , aud , iat ,
exp , nbf , or jti .
|
build |
InvalidTypeForAdditionalClaim |
If the claim used in the child element <Claim>
of the <AdditionalClaims> element is not of type string , number ,
boolean , or map , the deployment will fail.
|
build |
MissingNameForAdditionalClaim |
If the name of the claim is not specified in the child element <Claim>
of the <AdditionalClaims> element, the deployment will fail.
|
build |
InvalidNameForAdditionalHeader |
This error ccurs when the name of the claim used in the child element <Claim>
of the <AdditionalClaims> element is either alg or typ .
|
build |
InvalidTypeForAdditionalHeader |
If the type of claim used in the child element <Claim>
of the <AdditionalClaims> element is not of type string , number ,
boolean , or map , the deployment will fail.
|
build |
InvalidValueOfArrayAttribute |
This error occurs when the value of the array attribute in the child element <Claim>
of the <AdditionalClaims> element is not set to true or false .
|
build |
InvalidConfigurationForActionAndAlgorithm |
If the <PrivateKey> element is used with HS Family algorithms or
the <SecretKey> element is used with RSA Family algorithms, the
deployment will fail.
|
build |
InvalidValueForElement |
If the value specified in the <Algorithm> element is not a supported value,
the deployment will fail.
|
build |
MissingConfigurationElement |
This error will occur if the <PrivateKey> element is not used with
RSA family algorithms or the <SecretKey> element is not used with HS Family
algorithms.
|
build |
InvalidKeyConfiguration |
If the child element <Value> is not defined in the <PrivateKey>
or <SecretKey> elements, the deployment will fail.
|
build |
EmptyElementForKeyConfiguration |
If the ref attribute of the child element <Value> of the <PrivateKey>
or <SecretKey> elements is empty or unspecified, the deployment will fail.
|
build |
InvalidVariableNameForSecret |
This error occurs if the flow variable name specified in the ref attribute of the child
element <Value> of the <PrivateKey>
or <SecretKey> elements does not contain the private prefix (private.) .
|
build |
InvalidSecretInConfig |
This error occurs if the child element <Value> of the <PrivateKey>
or <SecretKey> elements does not contain the private prefix (private.) .
|
build |
InvalidTimeFormat |
If the value specified in the<NotBefore> element does not use a
supported format, the deployment will fail.
|
build |
Fault variables
These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.
Variables | Where | Example |
---|---|---|
fault.name="fault_name" |
fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. | fault.name Matches "TokenExpired" |
JWT.failed |
All JWT policies set the same variable in the case of a failure. | JWT.failed = true |
Example error response
For error handling, the best practice is to trap the errorcode
part of the error
response. Do not rely on the text in the faultstring
, because it could change.
Example fault rule
<FaultRules> <FaultRule name="JWT Policy Errors"> <Step> <Name>JavaScript-1</Name> <Condition>(fault.name Matches "TokenExpired")</Condition> </Step> <Condition>JWT.failed=true</Condition> </FaultRule> </FaultRules>