Criterio VerifyAPIKey

Policy estensibile

Questa pagina si applica ad Apigee e Apigee hybrid.

Visualizza la documentazione di Apigee Edge.

Quando uno sviluppatore registra un'app su Apigee, Apigee genera automaticamente una coppia di chiave e secret consumer. Puoi visualizzare la coppia di chiave e secret del consumatore dell'app nell'interfaccia utente di Apigee o accedervi dall'API Apigee.

Nota:le chiavi API hanno molti nomi. Potresti vederle chiamate "chiavi API", "chiavi app" e "chiavi consumer". Tutti questi nomi sono sinonimi.

Al momento della registrazione dell'app, lo sviluppatore seleziona uno o più prodotti API da associare all'app, dove un prodotto API è una raccolta di risorse accessibili tramite proxy API. Lo sviluppatore passa quindi la chiave API (chiave consumer) come parte di ogni richiesta a un'API in un prodotto API associato all'app. Per informazioni, consulta la Panoramica della pubblicazione.

Il criterio VerifyAPIKey consente di applicare la verifica delle chiavi API in fase di runtime, consentendo solo alle app con chiavi API approvate di accedere alle tue API. Questa policy garantisce che le chiavi API siano valide, non siano state revocate e siano approvate per l'utilizzo delle risorse specifiche associate ai tuoi prodotti API.

Le chiavi API possono essere utilizzate come token di autenticazione oppure per ottenere token di accesso OAuth. In OAuth, le chiavi API sono chiamate "ID client". I nomi possono essere utilizzati in modo intercambiabile. Per saperne di più, consulta la home page di OAuth.

Apigee compila automaticamente un insieme di variabili di flusso durante l'esecuzione del criterio Verifica chiave API. Per saperne di più, consulta la sezione Variabili del flusso di seguito.

Queste norme sono estendibili e il loro utilizzo potrebbe avere implicazioni in termini di costi o utilizzo, a seconda della licenza Apigee. Per informazioni sui tipi di policy e sulle implicazioni di utilizzo, consulta Tipi di policy.

Per un tutorial che mostra come creare un proxy API che utilizza il criterio Verifica chiave API, consulta Proteggere un'API richiedendo chiavi API.

Esempi

Chiave nel parametro di query

<VerifyAPIKey name="APIKeyVerifier">
    <APIKey ref="request.queryparam.apikey" />
</VerifyAPIKey>

In questo esempio, il criterio prevede di trovare la chiave API in una variabile di flusso chiamata request.queryparam.apikey. La variabile request.queryparam.{name} è una variabile di flusso Apigee standard che viene compilata con il valore di un parametro di query passato nella richiesta del client.

Il seguente comando curl passa la chiave API in un parametro di query:

curl http://myorg-test.apigee.net/mocktarget?apikey=IEYRtW2cb7A5Gs54A1wKElECBL65GVls

Sebbene sia consentito, in genere è una pratica sconsigliata passare la chiave API in un parametro di query. Il motivo è che i parametri di query possono essere visualizzati nella cronologia del browser e nei log di rete, il che rappresenta un possibile rischio per la sicurezza. Una best practice consiste nell'inserire la chiave API in un'intestazione, che non verrà visualizzata nei file di log. Consulta l'esempio "KEY IN HEADER" nella scheda successiva.

Chiave nell'intestazione

<VerifyAPIKey name="APIKeyVerifier">
    <APIKey ref="request.header.x-apikey" />
</VerifyAPIKey>

In questo esempio, il criterio prevede di trovare la chiave API in una variabile di flusso chiamata request.header.x-apikey. La variabile request.header.{name} è una variabile di flusso Apigee standard che viene compilata con il valore di un'intestazione passata nella richiesta del client.

Il seguente cURL mostra come passare la chiave API in un'intestazione:

curl "http://myorg-test.apigee.net/mocktarget" -H "x-apikey:IEYRtW2cb7A5Gs54A1wKElECBL65GVls"

È consigliabile passare la chiave API in un'intestazione anziché in un parametro di query. Il motivo è che le intestazioni non vengono visualizzate nella cronologia del browser o nei log di rete, il che potrebbe rappresentare un possibile rischio per la sicurezza.

Chiave nella variabile

<VerifyAPIKey name="APIKeyVerifier">
    <APIKey ref="requestAPIKey.key"/>
</VerifyAPIKey>

Il criterio può fare riferimento a qualsiasi variabile che contenga la chiave. Le norme in questo esempio estraggono la chiave API da una variabile denominata requestAPIKey.key.

Il modo in cui viene compilata la variabile dipende da te. Ad esempio, puoi utilizzare la norma Estrai variabili per compilare requestAPIKey.key da un parametro di query denominato myKey, come mostrato di seguito:

<ExtractVariables async="false" continueOnError="false" enabled="true" name="SetAPIKeyVar">
    <Source>request</Source>
    <QueryParam name="myKey">
        <Pattern ignoreCase="true">{key}</Pattern>
    </QueryParam>
    <VariablePrefix>requestAPIKey</VariablePrefix>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</ExtractVariables>

Variabili di flusso delle policy di accesso

<AssignMessage async="false" continueOnError="false" enabled="true" name="accessverifyvars">
    <AssignVariable>
        <Name>devFirstName</Name>
        <Ref>verifyapikey.verify-api-key.developer.firstName</Ref>
        <Value>ErrorOnCopy</Value>
    </AssignVariable>
    <AssignVariable>
        <Name>devLastName</Name>
        <Ref>verifyapikey.verify-api-key.developer.lastName</Ref>
        <Value>ErrorOnCopy</Value>
    </AssignVariable>
    <AssignVariable>
        <Name>devEmail</Name>
        <Ref>verifyapikey.verify-api-key.developer.email</Ref>
        <Value>ErrorOnCopy</Value>
    </AssignVariable>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
    <AssignTo createNew="false" transport="http" type="request"/>
</AssignMessage>

Apigee compila automaticamente un insieme di variabili di flusso durante l'esecuzione del criterio Verifica chiave API per una chiave API valida. Puoi utilizzare queste variabili per accedere a informazioni quali il nome dell'app, l'ID app e informazioni sullo sviluppatore o sull'azienda che ha registrato l'app. Nell'esempio precedente, utilizzi il criterio Assegna messaggio per accedere al nome, al cognome e all'indirizzo email dello sviluppatore dopo l'esecuzione di Verifica chiave API.

Tutte queste variabili sono precedute da:

verifyapikey.{policy_name}

In questo esempio, il nome del criterio Verifica chiave API è "verify-api-key". Pertanto, fai riferimento al nome dello sviluppatore che effettua la richiesta accedendo alla variabile verifyapikey.verify-api-key.developer.firstName.

Impara a usare Apigee

Esempio: impara facendo!
L'esempio Proteggi il proxy con una chiave API protegge un proxy API con una chiave API e Rimuovi il parametro di query apikey mostra come rimuovere la chiave API dalla richiesta per impedirne il passaggio alla destinazione di backend (una best practice). Basta clonare il repository e seguire le istruzioni nei file README.

---

Riferimento elemento

Di seguito sono riportati gli elementi e gli attributi che puoi configurare in queste norme:

<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key-1">
    <DisplayName>Custom label used in UI</DisplayName>
    <APIKey ref="variable_containing_api_key"/>
    <CacheExpiryInSeconds ref="request.queryparam.cache_expiry">Default value</CacheExpiryInSeconds/>
</VerifyAPIKey>

Attributi di <VerifyAPIKey>

L'esempio seguente mostra gli attributi del tag <VerifyAPIKey>:

<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key-1">

La tabella seguente descrive gli attributi comuni a tutti gli elementi principali dei criteri:

Attributo	Descrizione	Predefinito	Presence
name	Il nome interno del criterio. Il valore dell'attributo name può contenere lettere, numeri, spazi, trattini, trattini bassi e punti. Questo valore non può superare i 255 caratteri. Se vuoi, utilizza l'elemento <DisplayName> per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso in linguaggio naturale.	N/D	Obbligatorio
continueOnError	Imposta su false per restituire un errore quando un criterio non va a buon fine. Questo è un comportamento previsto per la maggior parte dei criteri. Imposta su true per continuare l'esecuzione del flusso anche dopo un fallimento del criterio. Vedi anche: Le regole di errore vengono attivate SOLO in uno stato di errore (informazioni su continueOnError) Gestione degli errori all'interno del flusso corrente	falso	Facoltativo
enabled	Imposta su true per applicare il criterio. Imposta su false per disattivare il criterio. Il criterio non verrà applicato anche se rimane collegato a un flusso.	true	Facoltativo
async	Questo attributo è stato ritirato.	falso	Deprecato

Elemento <DisplayName>

Da utilizzare insieme all'attributo name per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso in linguaggio naturale.

<DisplayName>Policy Display Name</DisplayName>

Predefinito	N/D Se ometti questo elemento, viene utilizzato il valore dell'attributo name del criterio.
Presence	Facoltativo
Tipo	Stringa

Elemento <APIKey>

Questo elemento specifica la variabile di flusso che contiene la chiave API. In genere, il client invia la chiave API in un parametro di query, un'intestazione HTTP o un parametro del modulo. Ad esempio, se la chiave viene inviata in un'intestazione denominata x-apikey, la chiave verrà trovata nella variabile: request.header.x-apikey

Predefinito	ND
Presenza	Obbligatorio
Tipo	Stringa

Attributi

La tabella seguente descrive gli attributi dell'elemento <APIKey>.

Attributo	Descrizione	Predefinito	Presenza
ref	Un riferimento alla variabile che contiene la chiave API. È consentita una sola posizione per criterio.	N/D	Obbligatorio

È buona norma passare la chiave API in un'intestazione o in un parametro del modulo anziché in un parametro di query. Il motivo è che parametri di ricerca possono essere visualizzati nelle cronologie dei browser e nei log di rete, il che potrebbe rappresentare un potenziale rischio per la sicurezza.

Esempi

In questi esempi, la chiave viene passata nei parametri e in un'intestazione chiamata x-apikey.

Come parametro di query:

<VerifyAPIKey name="APIKeyVerifier">
    <APIKey ref="request.queryparam.x-apikey"/>
</VerifyAPIKey>

Come intestazione HTTP:

<VerifyAPIKey name="APIKeyVerifier">
    <APIKey ref="request.header.x-apikey"/>
</VerifyAPIKey>

Come parametro del modulo HTTP:

<VerifyAPIKey name="APIKeyVerifier">
    <APIKey ref="request.formparam.x-apikey"/>
</VerifyAPIKey>

Elemento <CacheExpiryInSeconds>

Questo elemento impone la durata (TTL) della cache, il che consente la personalizzazione del periodo di tempo per la scadenza della chiave API memorizzata nella cache. Puoi fornire una variabile di flusso e una variabile predefinita. Se fornito, il valore della variabile di flusso ha la precedenza sul valore predefinito specificato.

<CacheExpiryInSeconds ref="request.queryparam.cache_expiry">Value 1</CacheExpiryInSeconds>

Nota: le prestazioni diminuiscono quando l'intervallo di memorizzazione nella cache viene ridotto.

Predefinito	N/D Se ometti questo elemento, il periodo di scadenza predefinito per la chiave API memorizzata nella cache è di 180 secondi.
Presenza	Facoltativo
Tipo	Numero intero
Valori validi	Un numero intero compreso tra 1 e 180 inclusi. Specifica il tempo di scadenza in secondi.

Attributi

La tabella seguente descrive gli attributi dell'elemento <CacheExpiryInSeconds>.

Attributo	Descrizione	Predefinito	Presenza
ref	Un riferimento alla variabile di flusso contenente il valore per la scadenza della cache, espresso in secondi. Se fornito, il valore della variabile di flusso ha la precedenza sul valore predefinito specificato.	N/D	Facoltativo

Schemi

Esempio: consulta gli esempi del nostro repository GitHub per gli schemi più recenti.

Variabili di flusso

Quando un criterio Verifica chiave API viene applicato a una chiave API valida, Apigee compila un insieme di variabili di flusso. Queste variabili sono disponibili per le norme o il codice eseguiti in un secondo momento nel flusso e vengono spesso utilizzate per eseguire l'elaborazione personalizzata in base agli attributi della chiave API, come il nome dell'app, il prodotto API utilizzato per autorizzare la chiave o gli attributi personalizzati della chiave API.

I criteri compilano diversi tipi di variabili di flusso, tra cui:

• Generale
• App
• Sviluppatore
• Analytics
• Monetizzazione

Ogni tipo di variabile di flusso ha un prefisso diverso. Tutte le variabili sono scalari, tranne quelle specificamente indicate come array.

Variabili di flusso generali

La tabella seguente elenca le variabili di flusso generali compilate dal criterio Verifica chiave API. Tutte queste variabili sono precedute da:

verifyapikey.{policy_name}

Ad esempio: verifyapikey.{policy_name}.client_id

Le variabili disponibili includono:

Variabile	Descrizione
client_id	La chiave consumer (nota anche come chiave API o chiave app) fornita dall'app richiedente.
client_secret	Il secret consumer associato alla chiave consumer.
redirection_uris	Eventuali URI di reindirizzamento nella richiesta.
developer.app.id	L'ID dello sviluppatore o dell'app AppGroup che effettua la richiesta. Nota: non utilizzare la variabile developer.app.id per nessuno dei seguenti scopi: Identificatore per i criteri per le quote Chiavi Key Value Map (KVM) Identificatori inviati ai target da utilizzare nella logica di business di backend Questo ID viene generato internamente da Apigee e non è garantito che rimanga invariato nel tempo. Ad esempio, Apigee potrebbe modificare il formato o la lunghezza di questa variabile.
developer.app.name	Il nome dell'app dello sviluppatore o dell'app AppGroup che effettua la richiesta.
developer.id	L'ID dello sviluppatore o AppGroup registrato come proprietario dell'app richiedente. Nota: non utilizzare la variabile developer.id per nessuno dei seguenti scopi: Identificatore quota Tasti KVM Identificatori inviati ai target da utilizzare nella logica di business di backend Questo ID viene generato internamente da Apigee e non è garantito che rimanga invariato nel tempo. Ad esempio, Apigee potrebbe modificare il formato o la lunghezza di questa variabile.
developer.{custom_attrib_name}	Qualsiasi attributo personalizzato derivato dal profilo della chiave dell'app.
DisplayName	Il valore dell'attributo <DisplayName> del criterio.
failed	Impostato su "true" quando la convalida della chiave API non va a buon fine.
{custom_app_attrib}	Qualsiasi attributo personalizzato derivato dal profilo dell'app. Specifica il nome dell'attributo personalizzato. Nota:se l'attributo personalizzato App e l'attributo personalizzato Chiave app hanno lo stesso nome, l'attributo personalizzato Chiave app avrà la precedenza.
apiproduct.name*	Il nome del prodotto API utilizzato per convalidare la richiesta.
apiproduct.{custom_attrib_name}*	Qualsiasi attributo personalizzato derivato dal profilo del prodotto API.
apiproduct.developer.quota.limit*	Il limite di quota impostato sul prodotto API, se presente.
apiproduct.developer.quota.interval*	L'intervallo di quota impostato sul prodotto API, se presente.
apiproduct.developer.quota.timeunit*	L'unità di tempo della quota impostata sul prodotto API, se presente.
* Le variabili del prodotto API vengono compilate automaticamente se i prodotti API sono configurati con ambiente, proxy e risorse validi (derivati da proxy.pathsuffix). Per istruzioni sulla configurazione dei prodotti API, vedi Gestione dei prodotti API.

Variabili di flusso dell'app

Le seguenti variabili di flusso contenenti informazioni sull'app vengono compilate dalle norme. Tutte queste variabili sono precedute da:

verifyapikey.{policy_name}.app.

Ad esempio:

verifyapikey.{policy_name}.app.name

Le variabili disponibili includono:

Variabile	Descrizione
name	Il nome dell'app.
id	L'ID dell'app.
accessType	Non utilizzato da Apigee.
callbackUrl	L'URL di callback dell'app. In genere utilizzato solo per OAuth.
DisplayName	Il nome visualizzato dell'app.
status	Lo stato dell'app, ad esempio "approvata" o "revocata".
apiproducts	Un array contenente l'elenco dei prodotti API associati all'app.
appFamily	Qualsiasi famiglia di app contenente l'app o "predefinita".
appParentStatus	Lo stato del genitore dell'app, ad esempio "attivo" o "non attivo"
appType	Il tipo di app "Sviluppatore".
appParentId	L'ID dell'app principale.
created_at	Il timestamp di data/ora di creazione dell'app.
created_by	L'indirizzo email dello sviluppatore che ha creato l'app.
last_modified_at	Il timestamp di data/ora dell'ultimo aggiornamento dell'app.
last_modified_by	L'indirizzo email dello sviluppatore che ha aggiornato per l'ultima volta l'app.
{app_custom_attributes}	Qualsiasi attributo personalizzato dell'app. Specifica il nome dell'attributo personalizzato.

Variabili di flusso di AppGroup

Le seguenti variabili di flusso contenenti informazioni sui AppGroups vengono compilate dalle norme. Questi attributi di AppGroup vengono compilati solo se verifyapikey.{policy_name}.app.appType è "AppGroup".

Tutte queste variabili sono precedute da:

verifyapikey.{policy_name}.appgroup.

Ad esempio:

verifyapikey.{policy_name}.appgroup.name

Nota:se esegui la migrazione da Apigee Edge, le variabili di flusso dell'azienda sono disponibili automaticamente nell'attributo AppGroup corrispondente dopo la migrazione. Non sono necessarie modifiche ai bundle durante la migrazione.

Le variabili disponibili includono:

Variabile	Descrizione
name	Il nome dell'AppGroup.
id	L'ID AppGroup. Nota: questo ID viene generato internamente da Apigee e non è garantito che rimanga invariato nel tempo. Non utilizzare la variabile appgroup.id per nessuno dei seguenti scopi: Identificatore quota Tasti KVM Identificatori inviati ai target da utilizzare nella logica di business di backend
displayName	Il nome visualizzato di AppGroup.
appOwnerStatus	Lo stato del proprietario dell'app: "active" (attivo), "inactive" (non attivo) o "login_lock" (accesso bloccato).
created_at	Il timestamp di data/ora di creazione dell'AppGroup.
created_by	L'indirizzo email dello sviluppatore che ha creato l'AppGroup.
last_modified_at	Il timestamp di data/ora dell'ultima modifica dell'AppGroup.
last_modified_by	L'indirizzo email dello sviluppatore che ha modificato per l'ultima volta l'AppGroup.
{appgroup_custom_attributes}	Qualsiasi attributo personalizzato AppGroup. Specifica il nome dell'attributo personalizzato.

Variabili di flusso per sviluppatori

Le seguenti variabili di flusso contenenti informazioni sullo sviluppatore vengono compilate dalle norme. Tutte queste variabili sono precedute da:

verifyapikey.{policy_name}.developer

Ad esempio:

verifyapikey.{policy_name}.developer.id

Le variabili disponibili includono:

Variabile	Descrizione
id	Restituisce {org_name}@@@{developer_id}
userName	Il nome utente dello sviluppatore.
firstName	Il nome dello sviluppatore.
lastName	Il cognome dello sviluppatore.
email	L'indirizzo email dello sviluppatore.
status	Lo stato dello sviluppatore, ovvero attivo, non attivo o login_lock.
apps	Un array di app associate allo sviluppatore. Nota: l'accesso a questa variabile comporta una latenza elevata quando il numero di app è superiore a 10.
created_at	Il timestamp di data/ora di creazione dello sviluppatore.
created_by	L'indirizzo email dell'utente che ha creato lo sviluppatore.
last_modified_at	Il timestamp di data/ora dell'ultima modifica dello sviluppatore.
last_modified_by	L'indirizzo email dell'utente che ha modificato lo sviluppatore.
{developer_custom_attributes}	Qualsiasi attributo sviluppatore personalizzato. Specifica il nome dell'attributo personalizzato.

Variabili di Analytics

Le seguenti variabili vengono compilate automaticamente in Analytics quando viene applicata una policy Verifica chiave API per una chiave API valida. Queste variabili vengono compilate solo dalle norme Verifica chiave API e dalle norme OAuth.

Le variabili e i valori possono essere utilizzati come dimensioni per creare report di Analytics per ottenere visibilità sui pattern di consumo di sviluppatori e app.

• apiproduct.name
• developer.app.name
• client_id
• developer.id

Variabili di flusso di monetizzazione

Dopo l'autenticazione dell'utente, il criterio VerifyAPIKey controlla tutti i piani tariffari pubblicati per determinare quale, se presente, è attivo in base agli orari di attivazione e scadenza. Se viene trovato un piano tariffario pubblicato attivo, vengono compilate le seguenti variabili di flusso:

Variabile	Descrizione
mint.mintng_is_apiproduct_monetized	true se viene trovato un piano tariffario pubblicato attivo.
mint.mintng_rate_plan_id	ID piano tariffario.
mint.rateplan_end_time_ms	Ora di scadenza del piano tariffario. Ad esempio: 1619433556408
mint.rateplan_start_time_ms	Ora di attivazione del piano tariffario. Ad esempio: 1618433956209

Messaggi di errore

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	Cause
keymanagement.service.consumer_key_missing_api_product_association	400	The application credential is missing an API product association. Please associate the key's application with an API product. Note that this applies for all application types, such as developer apps and AppGroup apps.
keymanagement.service.DeveloperStatusNotActive	401	The developer who created the Developer App that has the API key you are using has an inactive status. When an App Developer's status is set to inactive, any Developer Apps created by that developer are deactivated. An admin user with appropriate permissions (such as Organization Administrator) can change a developer's status in the following ways: Apigee API: Set Developer Status Apigee UI: In Register app developers, see the instructions for deactivating (and activating) a developer.
keymanagement.service.invalid_client-app_not_approved	401	The Developer App associated with the API key is revoked. A revoked app cannot access any API products and cannot invoke any API managed by Apigee. An org admin can change the status of a Developer App using the Apigee API. See Generate Key Pair or Update Developer App Status.
oauth.v2.FailedToResolveAPIKey	401	The policy expects to find the API key in a variable that is specified in the policy's <APIKey> element. This error arises when the expected variable does not exist (it cannot be resolved).
oauth.v2.InvalidApiKey	401	An API key was received by Apigee, but it is invalid. When Apigee looks up the key in its database, it must exactly match the one that was sent in the request. If the API worked previously, make sure the key was not regenerated. If the key was regenerated, you will see this error if you try to use the old key. For details, see Controlling access to your APIs by registering apps.
oauth.v2.InvalidApiKeyForGivenResource	401	An API key was received by Apigee, and it is valid; however, it does not match an approved key in the Developer App associated with your API proxy through a Product.

Note: Currently, Apigee does not report the ApiKeyNotApproved error accurately. Instead, if a key is not approved (its status is set to revoked or pending), you will get the FailedToResolveAPIKey error instead. For more information and a possible workaround, see Verify api key not reporting api key not approved.

Deployment errors

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

Error name	Cause
SpecifyValueOrRefApiKey	The <APIKey> element does not have a value or key specified.

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 "FailedToResolveAPIKey"
oauthV2.policy_name.failed	policy_name is the user-specified name of the policy that threw the fault.	oauthV2.VK-VerifyAPIKey.failed = true

Example error responses

Note: 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.

{
   "fault":{
      "faultstring":"Invalid ApiKey",
      "detail":{
         "errorcode":"oauth.v2.InvalidApiKey"
      }
   }
}

{
   "fault":{
      "detail":{
         "errorcode":"keymanagement.service.DeveloperStatusNotActive"
      },
      "faultstring":"Developer Status is not Active"
   }
}

Example fault rule

<FaultRule name="FailedToResolveAPIKey">
    <Step>
        <Name>AM-FailedToResolveAPIKey</Name>
    </Step>
    <Condition>(fault.name Matches "FailedToResolveAPIKey") </Condition>
</FaultRule>