Renforcez votre entreprise : Connectez les outils d'IA à votre service existant avec le contrôle d'accès
Apprenez à renforcer votre entreprise en connectant de manière sécurisée des outils d'IA à vos services existants à l'aide de Tokens d'Accès Personnel et du Protocole de Contexte de Modèle (MCP), avec le code source complet et des exemples pratiques.
Bienvenue dans le guide sur la connexion des outils d'IA à vos services existants avec le contrôle d'accès !
Nous explorerons comment rendre vos services existants prêts pour les outils d'IA, surtout grâce à l'intégration avec LLM (en utilisant le Protocole de Contexte de Modèle) et divers agents d'IA, tout en abordant les défis du contrôle d'accès.
Grâce à ce guide, vous gagnerez :
- Intégration fluide de l'IA : Apprenez à connecter les outils d'IA à vos services, rendant vos données et fonctionnalités disponibles dans des environnements d'IA
- Sécurité API améliorée : Améliorez vos interfaces API pour protéger les données et la vie privée des utilisateurs avec un contrôle d'accès efficace
- Expérience IA personnalisée pour vos utilisateurs : Créez des expériences uniques assistées par l'IA pour chaque utilisateur grâce aux Tokens d'Accès Personnel
Nous fournissons des ressources tutoriels complètes, PROJET DE DÉMO COMPLET CODE SOURCE (FRONTEND, BACKEND et SERVEUR MCP INCLUS), et même des guides pratiques pour vous aider à construire des services prêts pour l'IA à partir de zéro.
Voilà comment ce guide peut améliorer votre entreprise :
- Avantage concurrentiel : Améliorez les capacités techniques et l'expérience utilisateur de votre service pour vous démarquer dans un marché concurrentiel
- Amélioration de la valeur utilisateur : Permettez aux utilisateurs de découvrir une valeur plus profonde dans votre produit grâce aux outils d'IA, augmentant les taux de rétention et la satisfaction
- Services prêts pour l'avenir : Intégration fluide de vos services avec l'écosystème IA, en préparation pour le paysage commercial de plus en plus axé sur l'IA et ouvrant des voies de croissance innovantes
Commençons !
Qu'est-ce que le MCP et comment connecte-t-il les outils d'IA à votre service
MCP (Protocole de Contexte de Modèle) est un protocole universel et ouvert qui standardise la manière dont les applications fournissent des informations contextuelles aux grands modèles de langage (LLM).
Le MCP se compose de plusieurs composants clés travaillant ensemble pour permettre aux outils d'IA d'accéder à vos services :
Dans ce guide, vous n'avez besoin de savoir que le serveur MCP est le point de connexion clé entre votre service et les outils d'IA. Il est responsable de fournir une série d'outils à utiliser par le LLM, et ces outils interagiront avec vos propres services. Pour plus de détails sur MCP, vous pouvez vous référer à Qu'est-ce que le MCP (Protocole de Contexte de Modèle) et comment ça fonctionne. Ici, nous nous concentrerons uniquement sur le serveur MCP.
Nous utiliserons un système de gestion de contenu (CMS) intégré avec des politiques de contrôle d'accès basé sur les rôles (RBAC) comme exemple. Nous créerons un serveur MCP pour lui et définirons un outil get-available-article-count
qui permet au LLM de récupérer le nombre d'articles disponibles pour l'utilisateur actuel dans le CMS :
C'est le code clé pour connecter le serveur MCP à votre service. Dans cette implémentation d'outil, il envoie une requête au point d'extrémité api/articles
du service et en retourne le résultat.
Cependant, cela est loin d'être suffisant, car l'API de votre service peut ne pas être publique. Chaque point d'extrémité a besoin d'un contrôle d'accès, et différents utilisateurs peuvent accéder à différentes ressources et données.
Ainsi, nous discuterons ensuite de la façon d'ajouter un contrôle d'accès à votre service.
Comment implémenter le contrôle d'accès pour le serveur MCP
Il est important de comprendre que les utilisateurs accédant à votre système via des outils d'IA sont les mêmes personnes qui pourraient utiliser directement votre système - le serveur MCP agit comme leur représentant lorsqu'ils interagissent via des outils d'IA.
Ainsi, lorsque les utilisateurs accèdent à vos services via des outils d'IA, deux défis pratiques de contrôle d'accès se posent :
- Comment le serveur MCP se connecte-t-il à votre système comme un utilisateur ?
- Votre système devrait-il redessiner tout son mécanisme de contrôle d'accès juste pour accueillir le serveur MCP ? Cela représenterait un coût et un effort considérables, surtout lorsque votre système d'origine possède déjà son propre mécanisme d'authentification
La clé pour résoudre ces problèmes est :
Comment les utilisateurs peuvent-ils permettre au serveur MCP d'accéder à votre service sans utiliser leurs identifiants et connexion interactive ?
Si vous pouvez résoudre ce problème, vous pouvez interagir directement avec votre service via le serveur MCP, et votre service peut continuer à utiliser le mécanisme de contrôle d'accès précédemment conçu pour les utilisateurs, sans avoir besoin de redessiner un nouveau système juste pour le serveur MCP !
Mais est-ce possible ?
Bien sûr que oui ! Nous pouvons parfaitement résoudre ce problème en utilisant les Tokens d'Accès Personnel !
Les tokens d'accès personnel (PATs) offrent un moyen sécurisé pour que les utilisateurs accordent un token d'accès sans utiliser leurs identifiants et connexion interactive. Cela est utile pour CI/CD, les scripts ou les applications qui ont besoin d'accéder aux ressources de manière programmatique.
Voici à quoi ressemble le flux de travail :
Ainsi, tant que votre système prend en charge les Tokens d'Accès Personnel (PAT), vous pouvez parfaitement résoudre les défis de contrôle d'accès entre les outils d'IA et vos services existants sans redessiner vos mécanismes d'authentification, tout en garantissant la sécurité des données et la protection de la vie privée de vos utilisateurs.
Passons maintenant à la partie pratique pour voir comment mettre en pratique cela.
Implémentation du contrôle d'accès du serveur MCP
Dans cette section, nous implémenterons le contrôle d'accès pour un serveur MCP en utilisant un système CMS existant comme base.
Vous pouvez consulter le tutoriel complet du CMS et le code source dans RBAC en pratique : Implémentation d'une autorisation sécurisée pour votre application, mais cela n'est pas obligatoire, nous couvrirons ici tous les principes essentiels.
L'exemple de CMS est basé sur Logto, une plateforme open-source d'identité populaire qui fournit une solution complète d'authentification et d'autorisation, mais l'implémentation technique n'est pas le focus de cet article.
Concevoir des permissions et une politique de contrôle d'accès pour votre service
La première étape de l'implémentation du contrôle d'accès est de concevoir des permissions et des politiques de contrôle d'accès pour votre système.
Dans notre exemple de CMS, nous avons conçu les points d'extrémité API suivants basés sur RBAC (Contrôle d'Accès Basé sur les Rôles) et spécifié les permissions requises pour accéder à chaque point d'extrémité :
Point d'extrémité | Logique de contrôle d'accès |
---|---|
GET /api/articles | - Toute personne avec la permission list:articles , OU les auteurs peuvent voir leurs propres articles |
GET /api/articles/:id | - Toute personne avec la permission read:articles , OU l'auteur de l'article |
POST /api/articles | - Toute personne avec la permission create:articles |
PATCH /api/articles/:id | - Toute personne avec la permission update:articles , OU l'auteur de l'article |
DELETE /api/articles/:id | - Toute personne avec la permission delete:articles , OU l'auteur de l'article |
PATCH /api/articles/:id/published | - Seuls les utilisateurs avec la permission publish:articles |
La conception des permissions du système est la suivante :
Permission | Description |
---|---|
list:articles | Voir la liste de tous les articles du système |
read:articles | Lire le contenu complet de n'importe quel article |
create:articles | Créer de nouveaux articles |
update:articles | Modifier n'importe quel article |
delete:articles | Supprimer n'importe quel article |
publish:articles | Modifier le statut de publication |
Sur la base de ces permissions, nous avons défini les rôles suivants pour notre système CMS :
Permission/Rôle | 👑 Administrateur | 📝 Éditeur | ✍️ Auteur |
---|---|---|---|
Description | Accès complet au système pour la gestion de contenu | Peut voir tous les articles et contrôler le statut de publication | Peut créer de nouveaux articles dans le système |
list:articles | ✅ | ✅ | ❌ |
read:articles | ✅ | ✅ | ❌ |
create:articles | ✅ | ❌ | ✅ |
update:articles | ✅ | ❌ | ❌ |
delete:articles | ✅ | ❌ | ❌ |
publish:articles | ✅ | ✅ | ❌ |
Remarque : Les auteurs ont automatiquement les permissions de lecture/modification/suppression pour leurs propres articles, indépendamment des permissions du rôle.
Ensuite, nous assignerons des rôles aux utilisateurs de notre système (en utilisant l'exemple de démonstration CMS) :
Utilisateur | Rôle |
---|---|
Alex | Administrateur |
Bob | Éditeur |
Charlie | Auteur |
Et dans Logto, comme mentionné dans l'article RBAC en pratique ci-dessus, nous avons configuré des rôles pour nos utilisateurs.
Appliquer la politique de contrôle d'accès à votre API de service
Voici comment les utilisateurs se connectent à notre exemple de CMS :
Ainsi, appliquer le contrôle d'accès à votre API de service est aussi simple que d'ajouter un middleware pour valider le token d'accès et vérifier les permissions à l'étape 9.
L'implémentation centrale est la suivante (consultez l'implémentation complète dans exemple RBAC - backend) :
Et appliquez le middleware aux points d'extrémité de l'API nécessitant une authentification :
Nous avons maintenant ajouté un contrôle d'accès à notre système CMS et assigné des rôles à nos utilisateurs.
Après que les utilisateurs se soient connectés et aient obtenu leur token d'accès pour l'API CMS, ils peuvent utiliser ce token pour accéder à l'API CMS. Le token d'accès contient les informations de permission de l'utilisateur. Cela nous permet de contrôler quelles données retourner selon les permissions de l'utilisateur.
Notre prochaine étape est d'implémenter le serveur MCP pour utiliser les Tokens d'Accès Personnel.
Comprendre comment le Token d'Accès Personnel représente les utilisateurs
En se référant au flux d'authentification CMS ci-dessus, les utilisateurs obtiennent un token d'accès pour l'API CMS après s'être connectés. Ce token d'accès est leur identifiant pour accéder à l'API CMS.
Nous avons juste besoin d'obtenir un token d'accès similaire à ce que les utilisateurs obtiennent après la connexion. Ensuite, nous pouvons l'utiliser pour accéder à l'API CMS.
C'est là que les Tokens d'Accès Personnel entrent en jeu. Ils nous aident à obtenir le même type de token d'accès que ce que les utilisateurs obtiennent normalement après la connexion.
Voici ce que nous devons faire :
- Créer un Token d'Accès Personnel pour un utilisateur
- Utiliser ce Token d'Accès Personnel pour demander un token d'échange auprès du point d'extrémité de token du Service Auth. Cela nous donne un token d'accès similaire à celui que les utilisateurs obtiennent après la connexion
- Utiliser ce token d'accès dans notre outil de service MCP pour accéder à l'API CMS
Dans cet exemple, nous utilisons Logto pour la démonstration, puisque Logto prend en charge les Tokens d'Accès Personnel et l'échange de token. Si vous n'utilisez pas Logto, vous pouvez suivre cette approche pour implémenter votre propre support pour les Tokens d'Accès Personnel.
Créer un Token d'Accès Personnel pour votre utilisateur
Dans la Console Logto > Gestion des utilisateurs, vous pouvez créer un Token d'Accès Personnel pour un utilisateur à partir de sa page de détails :
Lors de la création d'un Token d'Accès Personnel, vous pouvez définir son temps d'expiration si nécessaire.
Utilisation du Token d'Accès Personnel dans le serveur MCP
Maintenant que nous avons le Token d'Accès Personnel de l'utilisateur, nous pouvons l'utiliser dans notre serveur MCP.
Tout d'abord, suivons la documentation des Tokens d'Accès Personnel de Logto, nous obtiendrons un token d'accès pour accéder à l'API CMS à partir du point d'extrémité de token de Logto. Vous pouvez consulter le code source complet ici.
Dans le serveur MCP, nous utilisons le token d'accès de la fonction exchangeAccessToken
pour obtenir des données à partir de l'API CMS.
De cette manière, le serveur MCP n'a pas besoin des identifiants de connexion utilisateur pour accéder à l'API CMS. À la place, il utilise le Token d'Accès Personnel de l'utilisateur.
Vous pouvez trouver le code complet dans exemple RBAC - mcp-server。
Pour savoir comment déployer ce serveur MCP localement avec Claude Desktop, consultez le:guide de déploiement du serveur MCP。
Vous pouvez également déployer ce serveur sur divers IDE d'IA comme Cursor, Cline, Windsurf, etc.
Test du contrôle d'accès
Testons cette implémentation dans Claude Desktop.
Dans notre CMS, Alex et Charles ont chacun créé un article.
Étant donné qu'Alex a le rôle d'administrateur, il peut voir tous les articles. Charles, étant auteur, ne peut voir que ses propres articles.
Lorsque nous demandons à Claude combien d'articles disponibles il y a, Claude utilisera l'outil get-available-article-count
et demandera notre permission :
Lorsque nous utilisons le Token d'Accès Personnel d'Alex dans MCP et demandons à Claude le nombre d'articles disponibles, Claude appelle l'outil get-available-article-count
et nous dit qu'il y a 2 articles.
Lorsque nous passons au Token d'Accès Personnel de Charles et posons la même question, Claude nous dit qu'il n'y a qu'un seul article.
Super ! Nous avons réussi à utiliser des Tokens d'Accès Personnel pour accéder à l'API CMS et obtenir les données correctes.
C'est exactement ce que nous voulions : nous créons un Token d'Accès Personnel pour chaque utilisateur, et lorsque les utilisateurs configurent leur serveur MCP avec leur token, nous créons une expérience IA personnalisée pour eux.
Laissez-moi vous aider à rédiger la section Résumé :
Résumé
Dans ce guide, nous avons exploré comment connecter des outils d'IA à vos services existants tout en maintenant un contrôle d'accès approprié. Nous avons démontré cela à l'aide d'un système CMS avec une implémentation RBAC, montrant comment les Tokens d'Accès Personnel (PATs) peuvent résoudre avec élégance les défis d'authentification.
Vous pouvez trouver le code source complet de cette implémentation dans notre dépôt d'exemples RBAC, qui comprend l'implémentation du backend CMS, du frontend, et du serveur MCP.
Lors de la distribution de votre serveur MCP aux utilisateurs, n'oubliez pas de rendre le Token d'Accès Personnel configurable. Cela permet à chaque utilisateur de :
- Configurer son propre PAT dans le serveur MCP
- Accéder aux ressources en fonction de leurs permissions spécifiques
- Obtenir des expériences d'IA personnalisées qui reflètent leur rôle et leurs niveaux d'accès
Cette approche garantit que votre intégration IA reste sécurisée tout en offrant une expérience personnalisée à chaque utilisateur en fonction de leurs permissions et de leur rôle dans votre système.
Nous vous souhaitons un immense succès dans votre entreprise alors que vous vous lancez dans ce parcours d'intégration de l'IA ! Que vos services prospèrent et se développent avec ces nouvelles capacités IA ! 🚀