Secrets dans l’API Reactor

Dans l’API Reactor, un secret est une ressource qui représente des informations d’authentification. Les secrets sont utilisés dans le transfert d’événements pour s’authentifier auprès d’un autre système afin d’échanger des données en toute sécurité. Par conséquent, les secrets ne peuvent être créés que dans les propriétés de transfert d’événements (propriétés dont le nom du champ platform est défini sur edge).

Actuellement, trois types de secrets pris en charge sont identifiés dans le nom du champ type_of :

Ce guide fournit un aperçu général de la configuration des secrets pour une utilisation dans le transfert d’événements. Pour obtenir des instructions détaillées sur la gestion des secrets dans l’API Reactor, et notamment un exemple JSON de la structure d’un secret, reportez-vous au guide des points d’entrée des secrets.

Informations d’identification

Chaque secret contient un attribut credentials qui rassemble ses valeurs d’identification respectives. When création d’un secret dans l’API, chaque type de secret possède des attributs obligatoires différents, comme illustré dans les sections ci-dessous :

token token

Les secrets disposant d’une valeur type_of de token ne requièrent qu’un seul attribut sous credentials :

Le jeton est stocké en tant que valeur statique, et par conséquent les propriétés expires_at et refresh_at du secret sont définies sur null lorsque le secret est créé.

simple-http simple-http

Les secrets disposant d’une valeur type_of de simple-http nécessitent les attributs suivants sous credentials :

Lorsque le secret est créé, les deux attributs sont échangés avec un encodage BASE64 de username:password. Après l’échange, les propriétés expires_at et refresh_at du secret sont définies sur null.

oauth2-client_credentials oauth2-client_credentials

Les secrets disposant d’une valeur type_of de oauth2-client_credentials nécessitent les attributs suivants sous credentials :

Lorsqu’un secret oauth2-client_credentials est créé ou mis à jour, client_id et client_secret (et éventuellement options) sont échangés dans une requête POST contre token_url, selon le flux d’informations d’identification du client du protocole OAuth.

Si le service d’autorisation répond par 200 OK et un corps de réponse JSON, le corps est analysé et access_token est placé dans l’environnement Edge et expires_in est utilisé pour calculer les attributs expires_at et refresh_at pour le secret. S’il n’existe aucune association d’environnement sur le secret, access_token est ignoré.

Un échange d’informations d’identification est considéré comme réussi dans les conditions suivantes :

Si l’échange réussit, l’attribut status du secret est défini sur succeeded et les valeurs de expires_at et refresh_at sont définies :

Si l’échange échoue pour une raison quelconque, l’attribut status_details dans l’objet meta est mis à jour avec les informations pertinentes.

Actualisation d’un secret oauth2-client_credentials

Si un secret oauth2-client_credentials a été affecté à un environnement et que son statut est succeeded (les informations d’identification ont été échangées avec succès), un nouvel échange est automatiquement effectué sur refresh_at.

Si l’échange réussit, l’attribut refresh_status dans l’objet meta est défini sur succeeded tandis que expires_at, refresh_at et activated_at sont mis à jour en conséquence.

En cas d’échec de l’échange, l’opération est tentée trois fois de plus ; la dernière tentative a lieu au plus tard deux heures avant l’expiration du jeton d’accès. Si toutes les tentatives échouent, l’attribut refresh_status_details de l’objet meta est mis à jour avec les détails pertinents.

oauth2-google oauth2-google

Secrets avec un type_of valeur de oauth2-google nécessite l’attribut suivant sous credentials:

Après avoir créé la variable oauth2-google secret, la réponse comprend une meta.authorization_url . Vous devez copier et coller cette URL dans un navigateur pour terminer le flux d’authentification Google.

Réautoriser oauth2-google secret

L’URL d’autorisation d’un oauth2-google Le secret expire une heure après la création du secret (comme indiqué par meta.authorization_url_expires_at). Au-delà, le secret doit être réautorisé afin de renouveler le processus d'authentification.

Reportez-vous à la section guide de point de fin secrets pour plus d’informations sur la manière dont réautoriser une oauth2-google secret en adressant une demande de PATCH à l’API Reactor.

Relation entre les environnements

Lorsque vous créez un secret, vous devez spécifier l’environnement dans lequel il existera. Les secrets sont immédiatement déployés dans l’environnement dans lequel ils sont créés.

Un secret ne peut être associé qu’à un seul environnement. Une fois la relation entre un secret et un environnement établie, le secret ne peut pas être effacé de l’environnement, et il ne peut pas non plus être associé à un autre environnement.

Une fois les informations d’identification d’un secret échangées, pour qu’un secret soit associé à un environnement, l’artefact d’échange (la chaîne de jeton pour token, la chaîne codée Base64 pour simple-http ou le jeton d’accès pour oauth2-client_credentials) est enregistré en toute sécurité dans l’environnement.

Une fois l’artefact d’échange enregistré dans l’environnement, l’attribut activated_at du secret est défini sur l’heure UTC actuelle et peut alors être référencé à l’aide d’un élément de données. Voir la section suivante pour plus d’informations sur la référence aux secrets.

Référencer des secrets referencing-secrets

Pour référencer un secret, vous devez créer un élément de données de type « Secret » (fourni par l’extension Core) sur une propriété de transfert d’événements. Lors de la configuration de cet élément de données, vous êtes invité à indiquer le secret à utiliser pour chaque environnement. Vous pouvez ensuite créer des règles qui référencent un élément de données secret, comme dans l’en-tête d’un appel HTTP.

Au moment de l’exécution, l’élément de données secret est remplacé par l’artefact d’échange secret correspondant enregistré dans l’environnement.

Étapes suivantes

Ce guide décrit les principes de base de l’utilisation des secrets dans l’API Reactor. Pour plus d’informations sur la gestion des secrets à l’aide des appels API, voir la section guide des points d’entrée des secrets.