GenerateJWS-Richtlinie

Diese Seite gilt für Apigee und Apigee Hybrid.

Apigee Edge-Dokumentation aufrufen

Was

Generiert ein signiertes JWS mit einem konfigurierbaren Satz von Anforderungen. Das JWT kann dann an Clients zurückgegeben, an Back-End-Ziele übertragen oder auf andere Weise genutzt werden. Eine detaillierte Einführung finden Sie unter Übersicht über JWS- und JWT-Richtlinien.

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

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

Video

Hinweis: Das folgende Video zeigt den klassischen Proxy-Editor in der Apigee-UI. Apigee führt eine neue Version des Proxy-Editors ein, die ein anderes Design als die im Video gezeigte klassische Version hat.

In diesem kurzen Video erfahren Sie, wie Sie ein signiertes JWT generieren. Obwohl dieses Video speziell für die Generierung eines JWT gedacht ist, sind viele der Konzepte für JWS identisch.

Beispiele

Eine mit HS256 signierte JWS generieren

Diese Beispielrichtlinie generiert eine JWS, die mit dem HS256-Algorithmus signiert wurde. HS256 stützt sich auf ein gemeinsames Secret für die Signatur und die Verifizierung der Signatur. Diese JWS verwendet „angehängte” Inhalte, d. h., der codierte Header, die Nutzlast und die Signatur werden durch Punkte verkettet, um die endgültige JWS zu erzeugen:

[header].[payload].[signature]

Mit dem Element <Payload> geben Sie die nicht codierte JWS-Rohnutzlast an. In diesem Beispiel enthält eine Variable die Nutzlast. Wenn diese Richtlinienaktion ausgelöst wird, codiert Apigee den JWS-Header und die Nutzlast und fügt dann die codierte Signatur hinzu, um die JWS digital zu signieren.

Die folgende Richtlinienkonfiguration erstellt eine JWS aus einer Nutzlast, die in der Variablen my-payload enthalten ist, und speichert die resultierende JWS in der Variablen output-variable.

<GenerateJWS name="JWS-Generate-HS256">
    <DisplayName>JWS Generate HS256</DisplayName>
    <Algorithm>HS256</Algorithm>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <SecretKey>
        <Value ref="private.secretkey"/>
        <Id>1918290</Id>
    </SecretKey>
    <Payload ref="my-payload"/>
    <OutputVariable>output-variable</OutputVariable>
</GenerateJWS>

Ein mit HS256 signiertes JWT generieren

In diesem Beispiel wird auch eine JWS mit angehängten Inhalten generiert, die mit dem HS256-Algorithmus signiert wurden. In diesem Fall ist die Nutzlast JSON. Wenn Sie den typ-Header auf JWT setzen, wird ein signiertes JWS ausgegeben, das auch ein signiertes JWT ist. (Referenz)

Die folgende Richtlinienkonfiguration erstellt eine JWS aus einer Nutzlast, die in der Variablen json-content enthalten ist, und speichert die resultierende JWS in der Variablen output-variable. Das Ergebnis ist nur dann ein signiertes JWT, wenn die Variable json-content eine JSON-Nutzlast enthält und die Attribute innerhalb dieser JSON-Nutzlast für JWT gültig sind. Das Attribut exp muss beispielsweise einen numerischen Wert enthalten, sofern vorhanden. Das Attribut aud, sofern vorhanden, muss ein String oder ein Array von Strings sein. Dies sind nur einige Beispiele für die Bedeutung von Data Governance. Weitere Informationen zu den gültigen Werten für JWT-Anforderungen finden Sie unter IETF RFC7519.

<GenerateJWS name="JWS-Generate-HS256-JWT">
    <Algorithm>HS256</Algorithm>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <SecretKey>
        <Value ref="private.secretkey"/>
    </SecretKey>
    <Payload ref="json-content"/>
    <AdditionalHeaders>
        <Claim name="typ">JWT</Claim>
    </AdditionalHeaders>
    <OutputVariable>output-variable</OutputVariable>
</GenerateJWS>

Getrennte JWS generieren

Diese Beispielrichtlinie generiert eine JWS mit getrenntem Inhalt, die mit dem RS256-Algorithmus signiert wird. Das Generieren einer RS256-Signatur benötigt einen privaten RSA-Schlüssel, der in PEM-codierter Form bereitgestellt werden muss.

Eine JWS mit getrenntem Inhalt lässt die Nutzlast der generierten JWS aus:

[header]..[signature]

Weitere Informationen zur Struktur und zum Format einer JWS finden Sie unter Teile einer JWS/eines JWT.

Mit dem Element <Payload> geben Sie die nicht codierte JWS-Rohnutzlast an. Wenn diese Richtlinie ausgelöst wird, codiert Apigee den JWS-Header und die Nutzlast und verwendet sie anschließend zum Generieren der codierten Signatur. Die generierte JWS lässt die codierte Nutzlast jedoch aus der serialisierten JWS aus. Dies ist nützlich, wenn die signierten Inhalte groß oder binär sind (z. B. ein Bild oder eine PDF-Datei) oder beides. Um die Validierung zu ermöglichen, müssen beide Elemente, die JWS und die Nutzlast, die in dem signierten Inhalt enthalten war, an die überprüfende Partei übergeben werden. Wenn Sie die VerifyJWS-Richtlinie verwenden, um die JWS zu prüfen, können Sie die Variable mit der Nutzlast mit dem Element <DetachedContent> der VerifyJWS-Richtlinie angeben.

<GenerateJWS name="JWS-Generate-RS256">
    <DisplayName>JWS Generate RS256</DisplayName>
    <Algorithm>RS256</Algorithm>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <PrivateKey>
        <Value ref="private.privatekey"/>
        <Password ref="private.privatekey-password"/>
        <Id ref="private.privatekey-id"/>
    </PrivateKey>
    <Payload ref="my-payload"/>
    <DetachContent>true</DetachContent>
    <OutputVariable>output-variable</OutputVariable>
</GenerateJWS>

Hinweis: Sie können eine geringfügig modifizierte Version dieses Beispiels verwenden, um eine JWS für die PS*- oder ES*-Algorithmen zu generieren. Dazu ändern Sie einfach den Wert von <Algorithm>RS256</Algorithm> in PS256 oder ES256 usw. Der von Ihnen angegebene Schlüssel muss mit dem Algorithmus kompatibel sein. Weitere Informationen zu den Schlüsselanforderungen finden Sie unter Signaturverschlüsselungsalgorithmen.

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:

Hinweis: Die RS*-, PS*- und ES*-Algorithmen verwenden dieselben Elemente, um den Schlüssel anzugeben. Die von Ihnen angegebenen Schlüsseldaten müssen mit dem von Ihnen angegebenen Algorithmus kompatibel sein. Weitere Informationen zu den Schlüsselanforderungen finden Sie unter Signaturverschlüsselungsalgorithmen.

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 <Password> und <Id> sind optional.
^* Weitere Informationen zu den Schlüsselanforderungen finden Sie unter Signaturverschlüsselungsalgorithmen.

Elementreferenz für GenerateJWS

Die Richtlinienreferenz beschreibt die Elemente und Attribute der GenerateJWS-Richtlinie.

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

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

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

Attribut	Beschreibung	Standard	Presence
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.
Presence	Optional
Typ	String

<Algorithm>

<Algorithm>algorithm-here</Algorithm>

Gibt den Verschlüsselungsalgorithmus zum Signieren des Tokens an.

Standard	–
Presence	Erforderlich
Typ	String
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>

Fügt die zusätzlichen Paare aus Anforderungsname/Wert in den Header für die JWS ein.

Das Element <Claim> unterstützt das Feature zur dynamischen Stringersetzung mit dem Namen message templating, wenn type=map.

Standard	–
Presence	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, auch als Parameter bezeichnet.
• 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 der JWS den kritischen Header crit hinzu. Der Header crit ist ein Array aus Headernamen, die bekannt sein und vom JWS-Empfänger erkannt werden müssen. Sie können mit diesem Konfigurationselement beispielsweise einen JWS-Header erstellen, der bei der Decodierung so aussieht:

{
  "typ": "...",
  "alg" : "...",
  "hyb" : "some-value-here",
  "crit" : [ "hyb" ],
}

Dieser JWS-Header bestätigt, dass der Header-Parameter hyb von entscheidender Bedeutung ist und jeder Empfänger der JWS die Bedeutung und den Wert dieses Parameters verstehen muss.

Gemäß IETF RFC 7515 sollte der Empfänger einer JWS die JWS als ungültig ablehnen, wenn der Empfänger einen oder mehrere Parameter, auf die im crit-Parameter verwiesen wird, nicht versteht. In Apigee entspricht diesem Verhalten die VerifyJWS-Richtlinie. Für jeden im crit-Parameter aufgeführten Parameter wird geprüft, ob das <KnownHeaders>-Element der VerifyJWS-Richtlinie diesen Parameter ebenfalls enthält. Jeder Header, den die VerifyJWS-Richtlinie in crit findet, aber nicht in der <KnownHeaders>-Liste aufgeführt ist, veranlasst die VerifyJWS-Richtlinie, die JWS abzulehnen.

Hinweis: Es ist nicht sinnvoll, jegliche Headerparameter in die Liste der CriticalHeaders aufzunehmen, die im tatsächlichen JWS-Header nicht vorhanden sind. Mit <CriticalHeaders> werden die referenzierten Parameter nicht tatsächlich in den JWS-Header eingefügt. Es definiert nur den Inhalt des crit-Parameters. Sie können die <AdditionalHeader/Claims> verwenden, um die referenzierten Headeranforderungen oder Parameter hinzuzufügen.

Standard	–
Presence	Optional
Typ	Durch Kommas getrenntes Array aus einem oder mehreren Strings
Zulässige Werte	Entweder ein Array oder ein Verweis auf eine Variable, die das Array enthält.

<DetachContent>

<DetachContent>true|false</DetachContent>

Gibt an, ob die JWS mit einer getrennten Nutzlast (<DetachContent>true</DetachContent>) oder nicht (<DetachContent>false</DetachContent>) generiert werden soll.

Wenn Sie "false" angeben, hat die standardmäßig erstellte JWS folgendes Format:

[header].[payload].[signature]

Wenn Sie "true" festlegen, um eine JWS mit einer getrennten Nutzlast zu erstellen, wird die Nutzlast in der erzeugten JWS weggelassen. Sie hat das folgende Format:

[header]..[signature]

Bei einer JWS, die eine getrennte Nutzlast verwendet, können Sie die ursprüngliche, nicht codierte Nutzlast zusammen mit der serialisierten JWS an die prüfende Partei übergeben.

Standard	false
Presence	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
Presence	Optional
Typ	Boolesch
Zulässige Werte	"true" oder "false"

<OutputVariable>

<OutputVariable>output-variable</OutputVariable>

Gibt den Namen der Kontextvariablen an, die die Richtlinie mit der generierten JWS festlegen soll. Standardmäßig wird die JWS von der Richtlinie in die Kontextvariable namens jws.POLICYNAME.generated_jws eingefügt.

Standard	jws.POLICYNAME.generated_jws
Presence	Optional
Typ	String (Name einer Ablaufvariablen)

<Payload>

<Payload ref="flow-variable-name-here" />

or

<Payload>payload-value</Payload>

Gibt die unformatierte nicht codierte JWS-Nutzlast an. Geben Sie eine Variable mit der Nutzlast oder einen String an.

Das Element <Payload> unterstützt die Funktion zur dynamischen Stringsubstitution mit dem Namen Nachrichtenvorlagen. Mit einer Nachrichtenvorlage können Sie im String payload-value die Ersetzung von Variablenstrings durchführen. Im folgenden Beispiel würde die Nutzlast aus einer Kombination aus Text und dem Wert einer Variablen erstellt werden.

<Payload>fixed-text-{request.formparam.payload}-more-fixed-text</Payload>

Standard	–
Presence	Erforderlich
Typ	String, Byte-Array, Stream oder eine andere Darstellung der nicht codierten JWS-Nutzlast.
Zulässige Werte	Entweder eine Nachrichtenvorlage oder ein Verweis auf eine Variable, die die Nutzlast enthält.

<PrivateKey>-Element

Dies ist optional, und wird nur verwendet, wenn <Algorithm> eine der Optionen RS*, PS* oder ES* ist. Es gibt den privaten Schlüssel für Signieren sowie andere Informationen zum privaten Schlüssel an. Es wird verwendet, wenn der Algorithmus ein asymmetrischer Algorithmus ist.

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

Standard:	–
Präsenz:	Optional. Sie müssen jedoch genau eines der Elemente <PrivateKey> oder <SecretKey> angeben. Verwenden Sie das Element <PrivateKey>, wenn der Algorithmus RS*, PS* oder ES* ist, und verwenden Sie das Element <SecretKey>, wenn der Algorithmus HS* ist.
Typ:	–

<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 JWS-Header enthalten sein muss.

Standard	–
Presence	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.

Standard	–
Presence	Optional
Typ	String
Zulässige Werte	Eine Referenz für eine Ablaufvariable. Hinweis: Sie müssen eine Ablaufvariable mit dem Attribut ref angeben. Apigee lehnt Richtlinienkonfigurationen, in denen das Passwort im Klartext angegeben wird, als ungültig ab. Die Ablaufvariable muss das Präfix „private” haben. Zum Beispiele private.mypassword

<PrivateKey/Value>

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

Gibt einen PEM-codierten privaten Schlüssel an, der zum Signieren der JWS verwendet wird. Verwenden Sie das Attribut ref, um den Schlüssel in einer Ablaufvariable zu übergeben.

Standard	–
Presence	Erforderlich, wenn mit der Richtlinie eine JWS mithilfe eines der RS*-, PS*- oder ES*-Algorithmen generiert wird.
Typ	String
Zulässige Werte	Eine Ablaufvariable mit einem String, der einen privaten PEM-codierten Schlüsselwert darstellt. Hinweis: Die Ablaufvariable muss das Präfix "private" haben. Beispiel: private.mykey

<SecretKey>

<SecretKey encoding="base16|hex|base64|base64url" >
  <Id ref="variable-containing-key-id-here">secret-key-id</Id>
  <Value ref="private.variable-here"/>
</SecretKey>

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

Dieses Element ist optional. Sie müssen aber unbedingt entweder <PrivateKey> oder <SecretKey> angeben. Verwenden Sie das Element <PrivateKey>, wenn Sie eine JWS generieren, die mit einem asymmetrischen Algorithmus signiert ist (entweder RS*, PS* oder ES*), und das Element <SecretKey>, wenn Sie eine JWS signieren, die mit einen symmetrischen Algorithmus (wie HS*) signiert ist.

Untergeordnete Elemente von <SecretKey>

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

Kind	Presence	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="hex" > <Id ref="variable-containing-key-id-here">secret-key-id</Id> <Value ref="private.secretkey"/> </SecretKey> Da im obigen Beispiel die Codierung hex lautet, wird der Schlüssel als Satz von 9 Byte decodiert, wenn die Variable private.secretkey den Inhalt 494c6f766541504973 hat. Im hex-Format ist das 49 4c 6f 76 65 41 50 49 73. Hinweis: Apigee erzwingt eine Mindestschlüsselstärke. Weitere Informationen finden Sie in der Dokumentation zum Element Value.
Id (Element)	Optional	Die Schlüsselkennung. Der Wert kann ein beliebiger String sein. Sie können den Wert als Literaltextwert oder indirekt über eine Variablenreferenz mit dem Attribut ref angeben. <SecretKey> <Id ref="flow-variable-name-here"/> <Value ref="private.variable-here"/> </SecretKey> or <SecretKey> <Id>your-id-value-here</Id> <Value ref="private.variable-here"/> </SecretKey> Die Richtlinie enthält diese Schlüsselkennung als Anforderung kid im Header der generierten JWS.
Value (Element)	Erforderlich	Einen codierten geheimen Schlüssel Gibt den geheimen Schlüssel an, der zum Signieren der Nutzlast verwendet wird. Verwenden Sie das Attribut ref, um den Schlüssel indirekt über eine Variable wie private.secret-key bereitzustellen . <SecretKey> <Id ref="flow-variable-name-here"/> <Value ref="private.my-secret-variable"/> </SecretKey> Hinweis: Der Variablenname muss wie im Beispiel oben das private Präfix enthalten. 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.

<Type>

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

Optionales Element, dessen einziger erlaubter Wert Signed ist und angibt, dass die Richtlinie ein signiertes JWS generiert. <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	–
Presence	Optional
Typ	String
Gültiger Wert	Signed

Ablaufvariablen

Die GenerateJWS-Richtlinie legt keine Ablaufvariablen fest.

Fehlerreferenz

This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee 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.jws.GenerationFailed	401	The policy was unable to generate the JWS.
steps.jws.InsufficientKeyLength	401	For a key less than 32 bytes for the HS256 algorithm
steps.jws.InvalidClaim	401	For a missing claim or claim mismatch, or a missing header or header mismatch.
steps.jws.InvalidCurve	401	The curve specified by the key is not valid for the Elliptic Curve algorithm.
steps.jws.InvalidJsonFormat	401	Invalid JSON found in the JWS header.
steps.jws.InvalidPayload	401	The JWS payload is invalid.
steps.jws.InvalidSignature	401	<DetachedContent> is omitted and the JWS has a detached content payload.
steps.jws.KeyIdMissing	401	The Verify policy uses a JWKS as a source for public keys, but the signed JWS does not include a kid property in the header.
steps.jws.KeyParsingFailed	401	The public key could not be parsed from the given key information.
steps.jws.MissingPayload	401	The JWS payload is missing.
steps.jws.NoAlgorithmFoundInHeader	401	Occurs when the JWS omits the algorithm header.
steps.jws.SigningFailed	401	In GenerateJWS, for a key less than the minimum size for the HS384 or HS512 algorithms
steps.jws.UnknownException	401	An unknown exception occurred.
steps.jws.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	Occurs when
InvalidAlgorithm	The only valid values are: 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	Other possible deployment errors.

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"
JWS.failed	All JWS policies set the same variable in the case of a failure.	jws.JWS-Policy.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="JWS Policy Errors">
        <Step>
            <Name>JavaScript-1</Name>
            <Condition>(fault.name Matches "TokenExpired")</Condition>
        </Step>
        <Condition>JWS.failed=true</Condition>
    </FaultRule>
</FaultRules>