Règle VerifyJWS

<ph type="x-smartling-placeholder"></ph> Vous consultez la documentation Apigee Edge.
Accédez à la page Documentation sur Apigee X. En savoir plus

Quoi

Vérifie la signature sur un jeton JWS reçu de clients ou d'autres systèmes. Cette règle extrait également les en-têtes dans des variables de contexte afin que les règles ou les conditions ultérieures puissent examiner ces valeurs pour prendre des décisions concernant le processus d'autorisation ou de routage. Consultez la section Présentation des règles JWS et JWT pour une présentation détaillée.

Si le jeton JWS est valide, la requête est autorisée à poursuivre. Si la signature JWS ne peut pas être vérifiée ou si le jeton JWS n'est pas valide en raison d'une erreur, l'ensemble du traitement s'arrête et une erreur est renvoyée dans la réponse.

Pour en savoir plus sur les composantes d'un jeton JWS ainsi que sur la façon dont elles sont chiffrées et signées, consultez le document RFC7515.

Vidéo

Regardez une courte vidéo pour savoir comment vérifier la signature sur un jeton JWS. Bien que cette vidéo soit spécifique à la vérification d'un jeton JWT, de nombreux concepts sont les mêmes pour JWS.

Exemples

• Vérifier un jeton JWS associé signé avec l'algorithme HS256
• Vérifier un jeton JWS dissocié signé avec l'algorithme RS256

Vérifier un jeton JWS associé signé avec l'algorithme HS256

Cet exemple de règle vérifie un jeton JWS associé signé avec l'algorithme de chiffrement HS256, HMAC, à l'aide d'une somme de contrôle SHA-256. Le jeton JWS est transmis dans la requête de proxy à l'aide d'un paramètre de formulaire nommé JWS. La clé est contenue dans une variable nommée private.secretkey.

Un jeton JWS associé contient l'en-tête encodé, la charge utile et la signature :

header.payload.signature

La configuration de la stratégie inclut les informations dont Edge a besoin pour décoder et évaluer le JWS, par exemple où trouver JWS (dans une variable de flux spécifiée dans l'élément <Source>), l'algorithme de signature requis et où trouver la clé secrète (stockée dans une variable de flux Edge, qui pourrait ont été récupérées à partir de la KVM Edge, par exemple).

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

La règle écrit sa sortie dans des variables de contexte afin que les règles ou les conditions ultérieures du proxy d'API puissent examiner ces valeurs. Pour obtenir la liste des variables définies par cette règle, consultez la section Variables de flux.

Vérifier un jeton JWS dissocié signé avec l'algorithme RS256

Cet exemple de règle vérifie un jeton JWS dissocié signé avec l'algorithme RS256. Pour procéder à la vérification, vous devez fournir la clé publique. Le jeton JWS est transmis dans la requête de proxy à l'aide d'un paramètre de formulaire nommé JWS. La clé publique se trouve dans une variable nommée public.publickey.

Un JWS dissocié omet la charge utile de JWS :

header..signature

Il vous incombe de transmettre la charge utile à la règle VerifyJWS en spécifiant le nom de la variable contenant la charge utile dans l'élément <DetachedContent>. Le contenu spécifié dans <DetachedContent> doit être au même format non codé d'origine que celui défini lorsque la signature JWS a été créée.

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

La règle écrit sa sortie dans des variables de contexte afin que les règles ou les conditions ultérieures du proxy d'API puissent examiner ces valeurs. Pour obtenir la liste des variables définies par cette règle, consultez la section Variables de flux.

Définir les éléments de clé

Les éléments que vous utilisez pour spécifier la clé utilisée pour vérifier le JWS dépendent de l'algorithme choisi, comme indiqué dans le tableau suivant :

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

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

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

Documentation de référence des éléments

La référence de règle décrit les éléments et les attributs de la règle JWS Verify.

Remarque : La configuration diffère légèrement selon l'algorithme de chiffrement que vous utilisez. Référez-vous aux échantillons pour obtenir des exemples illustrant des configurations pour des cas d'utilisation spécifiques.

Attributs qui s'appliquent à l'élément de premier niveau

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

Les attributs suivants sont communs à tous les éléments parents de la règle.

<DisplayName>

<DisplayName>Policy Display Name</DisplayName>

Utilisez-le, en plus de l'attribut "name", pour appliquer un libellé à la règle dans l'éditeur de proxys de l'interface de gestion en utilisant un nom différent, en langage naturel.

<Algorithm>

<Algorithm>HS256</Algorithm>

Spécifie l'algorithme de chiffrement permettant de signer le jeton. Les algorithmes RS*/PS*/ES* utilisent une paire de clés publique/secrète, tandis que les algorithmes HS* utilisent une clé secrète partagée. Consultez également À propos des algorithmes de chiffrement de signature.

Vous pouvez spécifier plusieurs valeurs séparées par une virgule. Par exemple, "HS256, HS512" ou "RS256, PS256". Cependant, vous ne pouvez pas associer des algorithmes HS* ou des algorithmes ES* à d'autres algorithmes, car ils exigent un type de clé spécifique. Vous pouvez combiner les algorithmes RS* et PS*.

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

Vérifie que l'en-tête JWS contient la ou les paires nom/valeur de revendication supplémentaires spécifiées et que les valeurs de revendication déclarées correspondent.

Une revendication supplémentaire utilise un nom qui ne correspond pas à l'un des noms de revendication standards JWS enregistrés. La valeur d'une revendication supplémentaire peut être une chaîne, un nombre, une valeur booléenne, un mappage ou un tableau. Un mappage est simplement un ensemble de paires nom/valeur. La valeur d'une revendication de l'un de ces types peut être spécifiée explicitement dans la configuration de la règle ou indirectement via une référence à une variable de flux.

L'élément <Claim> utilise les attributs suivants :

• name : (obligatoire) nom de la revendication.
• ref (facultatif) : nom d'une variable de flux. Si elle est présente, la règle utilise la valeur de cette variable comme revendication. Si un attribut ref et une valeur de revendication explicite sont spécifiés, la valeur explicite est la valeur par défaut, et est utilisée si la variable de flux référencée n'est pas résolue.
• type : (facultatif) au choix : chaîne (par défaut), nombre, valeur booléenne ou mappage
• array : (facultatif) défini sur true pour indiquer que la valeur est un tableau de types. Valeur par défaut : "false".

<DetachedContent>

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

Une requête JWS générée avec une charge utile de contenu se présente sous la forme suivante :

header.payload.signature

Si vous utilisez la règle GenerateJWS pour créer une charge utile dissociée, le fichier JWS généré omet la charge utile et se présente sous la forme suivante :

header..signature

Pour une charge utile dissociée, il vous incombe de transmettre la charge utile à la règle VerifyJWS à l'aide de l'élément <DetachedContent>. La charge utile de contenu spécifiée doit être au même format non codé d'origine que celui défini lorsque la signature JWS a été créée.

La règle génère une erreur dans les cas suivants :

• <DetachedContent> est spécifié lorsque le fichier JWS ne contient pas de charge utile de contenu détaché (le code d'erreur est steps.jws.ContentIsNotDetached).
• <DetachedContent> est omis et le JWT dispose d'une charge utile de contenu dissociée (le code d'erreur est steps.jws.InvalidSignature).

<IgnoreCriticalHeaders>

<IgnoreCriticalHeaders>true|false</IgnoreCriticalHeaders>

Défini sur "false" si vous souhaitez que la règle génère une erreur lorsqu'un en-tête répertorié dans l'en-tête crit du fichier JWS n'est pas répertorié dans l'élément <KnownHeaders>. Définissez la valeur sur "true" pour que la règle VerifyJWS ignore les en-têtes crit.

Si vous êtes dans un environnement de test et que vous ne souhaitez pas que la règle échoue en raison d'un en-tête manquant, vous pouvez définir cet élément sur "true".

<IgnoreUnresolvedVariables>

<IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables>

Définissez la valeur sur "false" si vous souhaitez que la règle génère une erreur lorsqu'une variable référencée dans la règle ne peut être résolue. Définissez la valeur sur "true" pour traiter toute variable irrésolue comme une chaîne vide (null).

<KnownHeaders>

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

or:

<KnownHeaders ref=’variable_containing_headers’/>

La règle GenerateJWS utilise l'élément <CriticalHeaders> pour renseigner l'en-tête crit dans un jeton. Exemple :

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

La règle VerifyJWS examine l'en-tête crit dans le fichier JWS, le cas échéant. Pour chaque élément répertorié, il vérifie que l'élément <KnownHeaders> répertorie également cet en-tête. L'élément <KnownHeaders> peut contenir un sur-ensemble des éléments répertoriés dans crit. Il n'est nécessaire que tous les en-têtes répertoriés dans crit soient répertoriés dans l'élément <KnownHeaders>. Tout en-tête trouvé par la règle dans crit et non répertorié dans la section <KnownHeaders> entraîne l'échec de la règle ValiderJWS.

Vous pouvez éventuellement configurer la règle VerifyJWS pour ignorer l'en-tête crit en définissant l'élément <IgnoreCriticalHeaders> sur true.

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

Spécifie une valeur au format JWKS (RFC 7517) contenant un ensemble de clés publiques. À n'utiliser que lorsque l'algorithme est RS256/RS384/RS512, PS256/PS384/PS512 ou ES256/ES384/ES512.

Si le jeton JWS entrant a un ID de clé présent dans l'ensemble de JWKS, la règle utilise la clé publique appropriée pour vérifier la signature JWS. Pour en savoir plus sur cette fonctionnalité, consultez la section Utiliser un jeu de clés Web JSON (JWKS) pour vérifier un JWS/JWT.

Si vous extrayez la valeur à partir d'une URL publique, Edge met en cache le JWKS pendant une période de 300 secondes. Lorsque le cache expire, Edge récupère à nouveau les JWKS.

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

Spécifie la clé publique utilisée pour vérifier la signature sur le jeton JWS. Utilisez l'attribut "ref" pour transmettre la clé dans une variable de flux ou spécifiez directement la clé encodée au format PEM. À n'utiliser que lorsque l'algorithme est RS256/RS384/RS512, PS256/PS384/PS512 ou ES256/ES384/ES512.

<SecretKey/Value>

<SecretKey>
  <Value ref="private.your-variable-name"/>
</SecretKey>

Fournit la clé secrète utilisée pour vérifier ou signer les jetons avec un algorithme HMAC. Utilisez ce paramètre uniquement lorsque l'algorithme est HS256, HS384 ou HS512. Utilisez l'attribut ref pour transmettre la clé dans une variable de flux.

<source>

<Source>JWS-variable</Source>

Le cas échéant, spécifie la variable de flux dans laquelle la règle s'attend à trouver le jeton JWT à vérifier.

Flow variables

Upon success, the Verify JWS and Decode JWS policies set context variables according to this pattern:

jws.{policy_name}.{variable_name}

For example, if the policy name is verify-jws, then the policy will store the algorithm specified in the JWS to this context variable: jws.verify-jws.header.algorithm

Informations de référence sur les erreurs

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.

Deployment errors

These errors can occur when you deploy a proxy containing this policy.

Fault variables

These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.

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>