Partager via

Sécuriser l’accès aux serveurs MCP dans Gestion des API

S’APPLIQUE À : Développeur | Essentiel | Essentiel v2 | Standard | Standard v2 | Premium | Premium v2

Avec la prise en charge du serveur MCP dans Gestion des API, vous pouvez exposer et régir l’accès aux serveurs MCP et à leurs outils. Cet article explique comment sécuriser l’accès aux serveurs MCP gérés dans gestion des API, y compris les serveurs MCP exposés à partir d’API REST managées et les serveurs MCP existants hébergés en dehors de gestion des API.

Vous pouvez sécuriser l’accès entrant au serveur MCP (à partir d’un client MCP à gestion des API) et l’accès sortant (de Gestion des API au serveur MCP).

Sécuriser l’accès entrant

Authentification basée sur une clé

Si le serveur MCP est protégé par une clé d’abonnement Gestion des API transmise dans un en-tête Ocp-Apim-Subscription-Key, les clients MCP peuvent présenter la clé dans les requêtes entrantes et le serveur MCP peut valider la clé. Par exemple, dans Visual Studio Code, vous pouvez ajouter une section headers à la configuration du serveur MCP pour exiger la clé d’abonnement dans les en-têtes de requête :

{
  "name": "My MCP Server",
  "type": "remote",
  "url": "https://my-api-management-instance.azure-api.net/my-mcp-server",    
  "transport": "streamable-http",
  "headers": {
    "Ocp-Apim-Subscription-Key": "<subscription-key>"
  }
}

Remarque

Gérez en toute sécurité les clés d’abonnement à laide des paramètres de l’espace de travail Visual Studio Code ou des entrées sécurisées.

Authentification basée sur jeton (OAuth 2.1 avec Microsoft Entra ID)

Les clients MCP peuvent présenter des jetons OAuth ou des JWT émis par Microsoft Entra ID à l’aide d’un en-tête Authorization et validés par Gestion des API.

Par exemple, utilisez la stratégie validate-azure-ad-token pour valider les jetons de Microsoft Entra :

<validate-azure-ad-token tenant-id="your-entra-tenant-id" header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">     
    <client-application-ids>
        <application-id>your-client-application-id</application-id>
    </client-application-ids> 
</validate-azure-ad-token>

Transférer des jetons vers le back-end

Les en-têtes de requête sont automatiquement transférés (avec certaines exclusions) aux appels d’outils MCP, ce qui simplifie l’intégration avec les API en aval qui s’appuient sur des en-têtes pour le routage, le contexte ou l’authentification.

Si vous avez besoin d’un transfert explicite de l’en-tête Authorization pour valider les demandes entrantes, vous pouvez utiliser l’une des approches suivantes :

  • Définissez Authorization explicitement comme en-tête obligatoire dans les paramètres de l’API et transférez l’en-tête dans la stratégie Outbound.

    Exemple d’extrait de code de stratégie :

    <!-- Forward Authorization header to backend --> 
<set-header name="Authorization" exists-action="override"> 
    <value>@(context.Request.Headers.GetValueOrDefault("Authorization"))</value> 
</set-header>

  • Utilisez le gestionnaire d’informations d’identification et les stratégies de gestion des API (get-authorization-context, set-header) pour transférer en toute sécurité le jeton. Pour plus d’informations, consultez Accès sortant sécurisé .

Pour plus d’options d’autorisation entrantes et d’exemples, consultez :

Sécuriser l’accès sortant

Utilisez le gestionnaire d’informations d’identification de Gestion des API pour injecter en toute sécurité des jetons OAuth 2.0 pour les demandes d’API back-end effectuées par les outils serveur MCP.

Étapes de configuration de l’accès sortant OAuth 2

Étape 1 : inscrivez une application dans le fournisseur d’identité.

Étape 2 : réez un fournisseur d’informations d’identification dans Gestion des API lié au fournisseur d’identité.

Étape 3 : configurez les connexions dans le gestionnaire d’informations d’identification.

Étape 4 : appliquez des stratégies gestion des API pour extraire et attacher dynamiquement des informations d’identification.

Par exemple, la stratégie suivante récupère un jeton d’accès à partir du gestionnaire d’informations d’identification et le définit dans l’en-tête Authorization de la demande sortante :

<!-- Add to inbound policy. -->
<get-authorization-context
    provider-id="your-credential-provider-id" 
    authorization-id="auth-01" 
    context-variable-name="auth-context" 
    identity-type="managed" 
    ignore-error="false" />
<!-- Attach the token to the backend call -->
<set-header name="Authorization" exists-action="override">
    <value>@("Bearer " + ((Authorization)context.Variables.GetValueOrDefault("auth-context"))?.AccessToken)</value>
</set-header>

Pour obtenir un guide pas à pas pour appeler un exemple de back-end à l’aide d’informations d’identification générées dans le gestionnaire d’informations d’identification, consultez Configurer le gestionnaire d’informations d’identification - GitHub.

Contenu connexe

  • Last updated on