Présentation

L’accès inter-applications (XAA) permet aux agents IA d’appeler la Datadog API au nom des utilisateurs que votre organisation a déjà autorisés dans Okta. Sans cela, chaque utilisateur autorise l’agent individuellement via un écran de consentement dans le navigateur. Avec cela, votre administrateur Okta accorde cet accès une fois, de manière centralisée, et les utilisateurs ignorent l’étape de consentement par utilisateur.

Okta émet pour l’agent un jeton à courte durée de vie appelé ID-JAG (Identity Assertion JWT Authorization Grant). L’agent présente ce jeton à Datadog, et Datadog l’échange contre un jeton d’accès appartenant à l’utilisateur qui a initié l’appel. Comme Okta génère le jeton, vos administrateurs accordent et révoquent l’accès Datadog pour les agents IA depuis Okta.

En version préliminaire, l’accès inter-applications prend en charge Okta comme seul fournisseur d’identité et Claude comme seul agent.

Valeurs que vous échangez

La configuration déplace les valeurs dans les deux sens entre Datadog et Okta. Deux d’entre elles sont des URL d’émetteur qui nomment des systèmes différents, assurez-vous donc de saisir chacune au bon endroit.

Prérequis

• Votre organisation utilise Okta pour l’authentification unique SAML vers Datadog. L’accès inter-applications résout les utilisateurs via votre connexion SAML existante ; il ne fonctionne donc pas sans celle-ci. Voir Configurer l’authentification unique SAML.
• Chaque utilisateur qui utilise Claude existe dans votre organisation Datadog et est affecté à la fois à l’application Claude et à l’application Datadog dans Okta.
• Vous disposez de l’autorisation org_management dans Datadog. Pour configurer l’accès inter-applications via l’API au lieu de l’interface utilisateur, vous avez également besoin d’un jeton d’accès personnel (PAT), utilisé comme DD_TOKEN dans les exemples.
• Votre tenant Okta a les fonctionnalités AI Agent Identity Assertion et Agent to Agent Connections activées, et vous disposez d’un accès Super Administrateur Okta.

Configurer l’accès inter-applications dans Datadog

Effectuez les étapes Datadog avant les étapes Okta. Datadog rejette les jetons pour les organisations qui n’ont pas activé l’accès inter-applications ; configurer Okta en premier entraînera donc des échecs jusqu’à ce que vous ayez terminé ici.

Accédez à Organization Settings > Cross-App Access.

Activer l’accès inter-applications

Cliquez sur Enable. Ceci s’applique à l’ensemble de votre organisation. Cliquez sur Disable pour désactiver l’accès inter-applications plus tard.

Définissez votre URL d’émetteur Okta

Dans le champ Issuer URL, saisissez l’URL de l’émetteur de votre propre tenant Okta, puis cliquez sur Save. Datadog déduit l’emplacement des clés de signature de jeton à partir de cette valeur, elle doit donc être exacte.

L’URL de l’émetteur doit répondre à toutes les conditions suivantes, sinon Datadog la rejette:

• Utilisez https.
• Utilisez un sous-domaine de .okta.com, .oktapreview.com ou .okta-emea.com. Datadog rejette le domaine apex, donc example.okta.com fonctionne et okta.com ne fonctionne pas.

Cliquez sur Remove pour annuler la définition de l’émetteur. Datadog cesse d’accepter les jetons une fois que vous l’avez supprimé.

Copiez l’UUID de votre organisation

Copiez la valeur dans le champ Org UUID. Okta envoie cette valeur en tant que revendication aud_tenant, qui indique à Datadog quelle organisation est ciblée par un jeton lorsque plusieurs organisations partagent un même tenant Okta. Ce n’est pas la même chose que l’ID d’entreprise qu’Okta demande ailleurs.

Copiez l’ID client de l’agent

Le tableau Registered client IDs répertorie tous les agents pris en charge par Datadog pour l’accès inter-applications et l’ID client OAuth que chacun utilise. Copiez l’ID client de l’agent que vous configurez. Vous le saisirez dans Okta en tant que Client ID at resource.

Datadog ajoute des agents à ce tableau au fur et à mesure qu’il les prend en charge ; vérifiez donc le tableau plutôt que de réutiliser un ID client provenant d’une autre source.

Cliquez sur Manage app sur une ligne pour ouvrir les paramètres de périmètre de cet agent. Voir Contrôler les portées dans Datadog.

curl -X PATCH "<span class="js-region-param region-param" data-region-param="dd_api"></span>/api/v2/org_configs/mcp_cross_app_access_enabled" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DD_TOKEN}" \
  -d '{
    "data": {
      "type": "org_configs",
      "attributes": {
        "value": true
      }
    }
  }'

curl -X PUT "<span class="js-region-param region-param" data-region-param="dd_api"></span>/api/v2/login/org_configs/mcp_cross_app_access_issuer_url" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${DD_TOKEN}" \
  -d '{
    "data": {
      "type": "org_config",
      "attributes": {
        "issuer_url": "https://<YOUR_OKTA_SUBDOMAIN>.okta.com"
      }
    }
  }'

Terminez la configuration dans Okta

Terminez la configuration dans Okta Admin Console en tant que super administrateur. Cette section répertorie les valeurs attendues par Datadog et les champs Okta correspondants. Consultez la documentation sur l’accès inter-applications d’Okta pour plus de détails.

Configurez l’application Datadog en tant que serveur de ressources

Dans votre application Datadog, ouvrez l’onglet Resource Server et activez Cross-app access (XAA). Définissez les champs suivants.

L’URL de l’émetteur identifie le serveur d’autorisation Datadog, et non l’endpoint de jeton. Okta l’inscrit dans la revendication aud des jetons qu’il émet, et Datadog n’accepte un jeton que lorsque cette revendication correspond.

Remarque : Modifier l’URL de l’émetteur ultérieurement nécessite de supprimer et de recréer la connexion de ressource décrite dans Connect Claude à l’application Datadog.

Enregistrez Claude en tant qu’agent IA

Créez une entrée d’agent IA pour Claude dans Okta, puis échangez les clés avec Anthropic. Anthropic signe les requêtes qu’Okta reçoit, donc Okta a besoin de la clé publique d’Anthropic avant d’émettre un jeton.

1. Créez l’entrée d’agent IA pour Claude.
2. Attribuez des propriétaires à l’agent. Okta exige un propriétaire avant que vous puissiez l’activer.
3. Envoyez l’ID d’agent IA généré par Okta à Anthropic.
4. Ajoutez la clé publique renvoyée par Anthropic à l’entrée de l’agent IA, sous l’onglet Credentials.

Tant que la clé publique n’est pas en place, l’échange de jetons échoue même si toutes les autres valeurs sont correctes. Cet échange est manuel, commencez donc tôt.

Connectez Claude à l’application Datadog

Sur l’agent IA Claude, ajoutez l’application SAML Claude en tant qu’appelant délégué, puis connectez l’agent à votre application Datadog.

1. Dans l’onglet Delegations, ajoutez l’application Claude SAML en tant qu’appelant.

2. Dans l’onglet Resource connections, ajoutez une connexion de ressource. Sélectionnez Application comme type de ressource, puis sélectionnez votre application Datadog.

3. Définissez les champs suivants.

   Champ Okta	Valeur
   Client ID at resource	L’ID client Claude que vous avez copié depuis Registered client IDs
   Scope Condition	Allow all, la seule valeur prise en charge. Voir Contrôler les portées dans Datadog

4. Activez l’agent depuis le menu Actions.

Contrôler les portées dans Datadog

Allow all est la seule Scope Condition prise en charge pour l’accès inter-applications. Définissez-le dans Okta, puis restreignez ce à quoi Claude accède depuis Datadog.

Okta ne filtre pas les portées. Avec Allow all, Okta copie tout ce que Claude demande dans le jeton, ce qui fait de Datadog le point d’application.

Pour définir les portées autorisées pour Claude :

1. Accédez à Organization Settings > Mobile and Third-Party Access. Vous pouvez également cliquer sur Manage app à côté de Claude dans le tableau Registered client IDs sur la page Accès inter-applications.
2. Sélectionnez l’application Claude, puis sélectionnez l’onglet Scopes.
3. Utilisez la case à cocher Allowed pour chaque périmètre afin de contrôler ce à quoi Claude a accès.
4. Cliquez sur Enable pour enregistrer.

L’ajout ou la suppression d’un périmètre affecte tous les utilisateurs de votre organisation, et la suppression d’un périmètre révoque les autorisations existantes qui en dépendent. Voir Gestion des périmètres d’application.

Un périmètre qui n’est pas autorisé dans Datadog n’est jamais accordé, indépendamment de ce que demande le jeton.

Ajoutez Datadog en tant que connecteur dans Claude

1. Dans Claude, cliquez sur l’icône + en bas de n’importe quelle invite, puis cliquez sur Add Connector.
2. Recherchez Datadog dans le répertoire et activez le connecteur.
3. Terminez le flux de connexion lorsque vous y êtes invité.

Utilisez le connecteur Datadog du répertoire, et non un connecteur personnalisé.

Vérifiez la configuration

Connectez-vous à Claude en tant qu’utilisateur affecté aux deux applications Okta, puis exécutez une requête qui appelle Datadog. Un appel réussi confirme le chemin complet : Okta émet le jeton, Datadog l’accepte et Datadog identifie l’utilisateur.

Si un utilisateur s’est connecté avant que vous n’activiez l’accès inter-applications, demandez-lui de se déconnecter de Claude et de se reconnecter via Okta. Les sessions établies précédemment ne disposent pas du jeton d’identité dont l’agent a besoin.

Pour aller plus loin

Documentation, liens et articles supplémentaires utiles:

Configurez le Datadog MCP ServerDOCUMENTATION Accès mobile et tiersDOCUMENTATION Configurez l'authentification unique SAMLDOCUMENTATION