Authentification lors de la surveillance multi-étapes

De nombreuses API exigent que le client fournisse des informations d’identification qui permettent de vérifier son identité et d’autoriser l’accès. Les approches courantes incluent les schémas d’authentification HTTP envoyés dans les en-têtes (Basic, NTLM ou Digest), l’accès basé sur des jetons (comme OAuth 2.0, où un jeton d’accès est obtenu puis généralement envoyé dans un en-tête Authorization), le TLS mutuel avec un certificat client, ou une combinaison de ces méthodes.

Cet article décrit les options d’authentification basées sur les en-têtes HTTP et les jetons dans Uptrends. Pour vous authentifier à l’aide de certificats clients, consultez Authentification par certificat client.

Types d’authentification par défaut

La section Authentification de l’onglet Requête propose plusieurs façons d’envoyer des informations d’identification :

• Authentification Basic
• Authentification NTLM (Windows)
• Authentification Digest
• Authentification Bearer
• Aucune — sélectionnez cette option si l’étape ne nécessite pas d’authentification.

Authentification Basic

Utilise un nom d’utilisateur et un mot de passe pour l’authentification. Uptrends génère automatiquement l’en-tête Authorization. Vous n’avez pas besoin d’ajouter cet en-tête manuellement.

Uptrends peut d’abord appeler l’API sans envoyer votre nom d’utilisateur et votre mot de passe. Si l’authentification est requise, le serveur refuse l’accès et demande une authentification Basic. Ce scénario est appelé un challenge : le serveur répond avec 401 Unauthorized et un en-tête WWW-Authenticate: Basic.

Uptrends réessaie ensuite l’appel API avec votre nom d’utilisateur et votre mot de passe. Il combine vos informations d’identification sous la forme username:password, encode le résultat en Base64 et l’envoie dans l’en-tête Authorization. Même si Uptrends effectue plusieurs appels API, cela compte toujours comme une seule étape de moniteur.

Note

Si le serveur renvoie 403 Forbidden ou si l’en-tête WWW-Authenticate: Basic est manquant, le moniteur renvoie une erreur. Ajoutez manuellement l’en-tête Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= à l’étape du moniteur, afin que les informations d’identification soient transmises même sans challenge approprié. Pour le format de l’en-tête, consultez le schéma d’authentification Basic (RFC 7617).

Authentification NTLM (Windows)

Utilise un nom d’utilisateur et un mot de passe Windows ou Active Directory pour l’authentification. Uptrends génère automatiquement l’en-tête Authorization. Vous n’avez pas besoin d’ajouter cet en-tête manuellement.

Uptrends peut d’abord appeler l’API sans envoyer vos informations d’identification. Si l’authentification est requise, le serveur refuse l’accès et demande une authentification NTLM. Ce scénario est appelé un challenge : le serveur répond avec 401 Unauthorized et un en-tête WWW-Authenticate: NTLM.

Uptrends peut ensuite envoyer plusieurs requêtes HTTP pour vérifier votre identité avant que l’appel API ne réussisse. Même si Uptrends effectue plusieurs appels API, cela compte toujours comme une seule étape de moniteur.

Note

Si le serveur renvoie 403 Forbidden ou si l’en-tête WWW-Authenticate: NTLM est manquant, le moniteur renvoie une erreur. Contrairement à l’authentification Basic, il n’existe pas de solution de contournement simple par en-tête manuel. Si votre compte se trouve dans un domaine Windows, saisissez le nom d’utilisateur sous la forme YOURDOMAIN\username (par exemple, ACME\john).

Authentification Digest

Utilise un nom d’utilisateur et un mot de passe pour l’authentification. Uptrends génère automatiquement l’en-tête Authorization. Vous n’avez pas besoin d’ajouter cet en-tête manuellement.

Uptrends peut d’abord appeler l’API sans envoyer vos informations d’identification. Si l’authentification est requise, le serveur refuse l’accès et demande une authentification Digest. Ce scénario est appelé un challenge : le serveur répond avec 401 Unauthorized et un en-tête WWW-Authenticate: Digest.

Uptrends réessaie ensuite l’appel API. Il calcule une réponse basée sur MD5 à partir du nom d’utilisateur, du mot de passe, du challenge du serveur, de la méthode de requête et de l’URL, puis l’envoie dans l’en-tête Authorization. Le mot de passe lui-même n’est jamais envoyé. Même si Uptrends effectue plusieurs appels API, cela compte toujours comme une seule étape de moniteur.

Note

Si le serveur renvoie 403 Forbidden ou si l’en-tête WWW-Authenticate: Digest est manquant, le moniteur renvoie une erreur. Contrairement à l’authentification Basic, il n’existe pas de solution de contournement simple par en-tête manuel.

Authentification Bearer

Utilise un jeton bearer au lieu d’un nom d’utilisateur et d’un mot de passe. Uptrends ajoute automatiquement Authorization: Bearer <token> à la requête API de cette étape. Vous n’avez pas besoin d’ajouter cet en-tête manuellement. Contrairement aux autres types d’authentification, aucun challenge serveur n’est requis.

Note

Utilisez l’authentification Bearer lorsque vous disposez déjà d’un jeton. Utilisez l’authentification personnalisée (OAuth) lorsque vous devez d’abord obtenir un jeton, ou lorsque le jeton provient de la réponse d’une étape précédente.

Prise en charge des variables

Les champs nom d’utilisateur et mot de passe prennent en charge les variables. Vous pouvez créer des variables prédéfinies (par exemple : {{username}} et {{password}}) avec les valeurs appropriées, puis utiliser ces noms de variables dans les champs d’authentification.

Vous pouvez également utiliser des éléments de coffre-fort pour les informations d’identification.

Pour savoir comment utiliser les variables prédéfinies, consultez Variables Multi-step API.

Authentification personnalisée (y compris OAuth)

Note

Utilisez l’authentification Bearer lorsque vous disposez déjà d’un jeton. Utilisez l’authentification personnalisée (OAuth) lorsque vous devez d’abord obtenir un jeton ou lorsqu’un jeton provient de la réponse d’une étape précédente.

Si votre API utilise OAuth comme protocole d’authentification, vous aurez besoin d’une configuration plus élaborée. En fonction de votre API, vous pourrez avoir besoin de quelque chose de spécifique à votre situation. En particulier, OAuth 2.0 utilise au moins une requête distincte uniquement pour le processus d’authentification. Cette requête demande l’accès à l’API (en utilisant l’un des types d’authentification par défaut, en spécifiant les informations de connexion dans l’URL, ou même en effectuant une connexion à une page web). Une fois l’authentification réussie, le jeton d’accès OAuth est capturé et stocké dans une variable, afin de pouvoir être utilisé dans les requêtes suivantes.

Si vous n’utilisez pas OAuth mais un protocole différent, son fonctionnement peut néanmoins être similaire : vous devrez d’abord spécifier les informations de connexion qui “prouvent” votre identité à l’API. Le serveur API répondra ensuite en vous fournissant un jeton de connexion valide pendant une certaine durée. En capturant ce jeton et en le stockant dans une variable, vous pouvez exécuter une séquence de requêtes qui utilisent le jeton de connexion pour obtenir l’accès.

Configuration de l’authentification OAuth 2.0

Dans l’exemple suivant, nous allons configurer une forme simple d’authentification OAuth 2.0. Notre objectif est d’obtenir un jeton d’accès depuis l’API, que nous pourrons ensuite utiliser dans des requêtes ultérieures.

Pour ce faire, nous enverrons d’abord une requête contenant les champs OAuth appropriés. Dans ce cas, nous demandons l’accès sur la base d’un code d’autorisation, d’un identifiant client et d’un secret client. L’identifiant client et le secret client sont des valeurs fixes que nous pouvons définir comme variables prédéfinies. Dans notre configuration simple, le code d’autorisation sera également une valeur fixe, mais dans votre configuration, il peut être nécessaire de récupérer d’abord ce code d’autorisation à l’aide d’une étape distincte.

Nous allons d’abord ajouter ces valeurs aux variables prédéfinies :

Une fois ces variables définies, nous pouvons maintenant configurer une requête vers notre API en incluant des références à ces variables, ainsi que tout autre paramètre attendu par l’API. Dans la première étape de notre configuration multi-étapes, ajoutez cette URL :

GET https://myapi.com/oauth/token?grant_type=authorization_code&code={{authorizationcode}}&client_id={{clientid}}&client_secret={{clientsecret}}

Nous nous attendons à ce que l’API renvoie une structure de données contenant le jeton d’accès dont nous avons besoin, mais comment cette structure de données sera-t-elle formatée ? Pour nous assurer d’obtenir des données au format JSON, indiquons au serveur que nous n’accepterons que le format application/json en le spécifiant dans un en-tête HTTP :

Une fois cet en-tête spécifié, nous pouvons maintenant nous attendre à ce que la réponse ressemble à ceci :

{ "access_token":"SGV5ISBZb3UgZm91bmQgdGhpcyB0ZXh0IQ==", "token_type":"Bearer", "expires_in":86400 }

Il nous reste maintenant à capturer le champ access_token dans la réponse JSON. Pour ce faire, nous allons créer une nouvelle variable dans l’onglet Réponse de notre étape :

• La réponse devrait contenir du JSON, choisissez donc Response body as JSON comme source pour notre variable.
• Comme l’attribut access_token se trouve au niveau supérieur de notre structure de données, notre expression JSON est simplement access_token.
• Nous choisirons accesstoken comme nom de variable. C’est le nom auquel nous ferons référence dans les étapes suivantes.

Même si l’objectif principal de cette première étape est de capturer le jeton d’accès, elle effectue déjà également une certaine surveillance : si l’API renvoie une erreur à ce stade, ou si la réponse ne contient pas de jeton d’accès, cette étape le détectera et signalera une erreur.

Maintenant que nous disposons d’un jeton d’accès valide, nous pouvons enfin accéder à la méthode API réelle que nous voulons vérifier (par exemple, pour récupérer une liste de produits). Créez une nouvelle étape pour définir cet appel API. Après avoir spécifié la méthode et l’URL de cette nouvelle requête, nous allons transmettre le jeton d’accès que nous venons de capturer. Les API basées sur OAuth 2.0 attendent un en-tête HTTP appelé Authorization, avec une valeur Bearer {{accesstoken}}

Nous pouvons répéter cette opération pour chaque étape supplémentaire qui nécessite le même jeton d’accès.