Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les clients du protocole de contexte modèle (MCP) s’authentifient auprès d’Azure Databricks pour appeler des outils. Lorsqu’un outil accède à un service externe, des informations d’identification distinctes déterminent le compte fournisseur utilisé.
Cette page explique les méthodes d’authentification prises en charge pour les serveurs Unity Gateway et MCP sur Databricks Apps. Utilisez les guides de configuration pour configurer l’authentification de votre client, agent ou serveur MCP. Pour les listes d’accès IP, les politiques réseau et la connectivité privée, voir MCP networking.
Le diagramme suivant montre les deux étapes d’authentification pour un MCP externe accessible via Unity Gateway.
- Authentification entrante : Le client envoie un jeton Azure Databricks qui identifie un utilisateur ou un principal de service.
- Authentification sortante : Unity Gateway envoie le jeton du fournisseur externe au MCP. La méthode d’authentification configurée dans la connexion Unity Catalog détermine si elle utilise le compte fournisseur de chaque utilisateur ou un compte partagé.
Trouvez votre guide d’installation
Choisissez un guide pour les prérequis, les étapes de configuration et le code adapté à votre cas d’usage.
| Guide | Ce qu’il couvre |
|---|---|
| Connectez un agent de codage aux outils MCP | Ajoutez des MCP, autorisez l’accès du fournisseur et appelez les outils. Commencez par le quickstart de l'agent de codage si votre agent n'est pas encore connecté à Azure Databricks. |
| Connectez Claude Desktop ou web | Configurez un client OAuth et ajoutez le connecteur MCP. Pour un autre client professionnel, voir Autres clients MCP. |
| Connectez votre application aux outils MCP | Votre application sert plusieurs utilisateurs. Utilisez le jeton de chaque utilisateur, vérifiez la connexion de leur fournisseur et appelez les outils avec leurs permissions. |
| Construis et exécute un agent Python | Construis ou teste un agent localement. Connectez-vous avec le CLI, chargez les outils MCP et exécutez l’agent avec le framework que vous avez choisi. |
| Exposer une API REST en tant qu’outils MCP | Déploie un serveur MCP sur Databricks Apps, active l’autorisation utilisateur et configure une connexion HTTP à ton API. |
| Authentifiez une application sans assistance avec un principal de service | Configurez les identifiants OAuth M2M, puis utilisez-les avec le client Python MCP. |
| Enregistrer un MCP externe avec Unity Gateway | Enregistrez le serveur, choisissez sa méthode d’authentification et testez un outil. |
Utilisez les outils MCP avec l’accès Consommateur
Les utilisateurs peuvent appeler des outils MCP via Unity Gateway depuis des agents de codage, des applications personnalisées et des clients professionnels avec le droit Accès Consommateur. Ils n’ont pas besoin du droit Workspace access, qui donne accès aux outils d’auteur d’espaces de travail tels que les notebooks et les jobs.
Un administrateur accorde au consommateur l’accès et la permission d’appeler le MCP. Pour les MCP qui utilisent OAuth par utilisateur, les utilisateurs autorisent leur compte fournisseur via la page de connexion MCP.
L’accès Consommateur prend en charge l’utilisation des outils MCP. La gestion des MCP dans l’interface Unity Gateway nécessite un accès à l’espace de travail. Voir Capacités d’accès des consommateurs.
Authentification entrante prise en charge
Le client envoie un jeton Azure Databricks lorsqu’il appelle un MCP via Unity Gateway ou sur Databricks Apps. Ce jeton identifie l’utilisateur ou le principal de service Azure Databricks effectuant la demande.
| Votre cas d’utilisation | Méthode d’authentification à utiliser |
|---|---|
| Une personne se connecte depuis un agent de programmation ou un client professionnel. | OAuth utilisateur-à-machine (U2M) appelle le MCP comme l’utilisateur connecté. |
| Un agent ou un service non surveillé s’exécute sans utilisateur. | OAuth machine-à-machine (M2M) appelle le MCP comme un principal de service. |
| Votre application ou votre charge de travail possède déjà un jeton d’un fournisseur d’identité. | La fédération de jetons OAuth échange ce jeton contre un jeton OAuth Azure Databricks pour l’utilisateur ou le principal de service mappé. |
| Une intégration existante utilise un jeton d’accès personnel. | Le jeton d’accès personnel (PAT) appelle le MCP comme propriétaire du jeton. Pris en charge via Unity Gateway. Non pris en charge pour les serveurs MCP sur Databricks Apps. |
Authentification sortante prise en charge
L’authentification sortante détermine quelles informations d’identification un MCP externe ou un serveur principal reçoit. Unity Gateway gère les identifiants via les connexions Unity Catalog. Un serveur MCP sur Databricks Apps peut utiliser une connexion ou implémenter sa propre authentification backend.
Via les connexions Unity Catalog
Unity Gateway s’authentifie au MCP externe avec le jeton fournisseur configuré ou obtenu via sa connexion Unity Catalog.
Unity Gateway prend en compte les cinq méthodes d’authentification disponibles pour les connexions HTTP de Unity Catalog. Le MCP externe doit prendre en charge la méthode sélectionnée :
| Méthode prise en charge | Quand utiliser | Identité au MCP externe |
|---|---|---|
| Jeton du porteur | Tous les appelants partagent un jeton pour accéder au MCP. | Le compte représenté par le jeton partagé. |
| OAuth Machine-à-machine | Le MCP prend en charge les informations d’identification d’un client OAuth pour une identité du service partagée. | Identité de service configurée dans la connexion |
| OAuth Utilisateur-à-machine partagé | Le MCP exige la connexion de l’utilisateur, et tous les appelants doivent utiliser un seul compte fournisseur partagé. | Le compte fournisseur autorisé pour la connexion. |
| Enregistrement dynamique du client (DCR) | Le MCP prend en charge l’enregistrement automatique des clients OAuth et la connexion par utilisateur. | Le compte du fournisseur que l’appelant a autorisé. |
| OAuth Utilisateur-vers-Machine par utilisateur | Chaque utilisateur doit avoir accès via son propre compte fournisseur, en utilisant un client OAuth configuré. | Le compte du fournisseur que l’appelant a autorisé. |
MCPs fournis par Databricks
Pour les MCP de données tels que Databricks SQL, l'identité Azure Databricks de l'appelant détermine l'accès aux données sous-jacentes. Les MCP pour services externes, tels que GitHub, utilisent l’authentification du fournisseur comme décrit dans Via des connexions Unity Catalog. Voir les MCP fournis par Databricks pour les besoins de chaque serveur.
Agents et serveurs MCP sur Databricks Apps
Un agent ou serveur MCP sur Databricks Apps peut appeler Azure Databricks en utilisant l'autorisation d'application comme principal de service de l'application, ou l'autorisation utilisateur en tant qu'utilisateur actuel.
La destination détermine comment authentifier l’appel sortant :
- API Azure Databricks ou autres MCP via Unity Gateway : Utilisez l’autorisation de l’application pour appeler en tant qu’application, ou l’autorisation utilisateur pour appeler en tant qu’utilisateur actuel.
- API REST externes via le proxy de connexion HTTP : Le proxy s’authentifie auprès de l’API externe en utilisant la méthode de connexion sélectionnée. Pour appeler en tant que chaque utilisateur, combinez l’autorisation utilisateur Apps avec l’OAuth par utilisateur sur la connexion.
- API externes ou MCP appelés directement : Implémentez le flux d’authentification supporté par ce service sur votre serveur.
Pour la configuration, les périmètres requis et le code, voir Configurer l’authentification de l’agent et Exposer une API REST comme outils MCP.