Geef je bedrijf kracht: Verbind AI-tools met je bestaande service met toegangscontrole
Leer hoe je je bedrijf kunt versterken door AI-tools veilig met je bestaande services te verbinden met behulp van Persoonlijke Toegangstokens en Model Context Protocol (MCP), met complete broncode en praktische voorbeelden.
Welkom bij de gids over het verbinden van AI-tools met je bestaande services met toegangscontrole!
We zullen onderzoeken hoe je je bestaande services gereed maakt voor AI-tools, vooral via integratie met LLM (met behulp van Model Context Protocol)) en verschillende AI-agenten, terwijl we toegang controle uitdagingen aanpakken.
Door deze gids krijg je:
- Naadloze AI-integratie: Leer hoe je AI-tools met je services kunt verbinden, waardoor je data en functionaliteit beschikbaar worden in AI-omgevingen
- Verbeterde API-beveiliging: Verbeter je API-interfaces om data en gebruikersprivacy te beschermen met effectieve toegangscontrole
- Gepersonaliseerde AI-ervaring voor je gebruiker: Creëer unieke AI-geassisteerde ervaringen voor elke gebruiker via Persoonlijke Toegangstokens
We bieden complete tutorial bronnen, VOLLEDIG DEMO PROJECT BRONCODE (FRONTEND, BACKEND, en MCP SERVER INBEGREPEN), en zelfs praktische gidsen om je te helpen AI-gereed services vanaf de basis op te bouwen.
Hier is hoe deze gids je bedrijf kan verbeteren:
- Concurrentievoordeel: Verbeter de technische capaciteiten van je service en de gebruikerservaring om op te vallen in een concurrerende markt
- Waardeverbetering voor de gebruiker: Stel gebruikers in staat om diepere waarde in je product te ontdekken via AI-tools, waardoor retentiecijfers en tevredenheid toenemen
- Toekomstklare services: Integreer naadloos je services met het AI-ecosysteem, bereid je voor op de aanstaande AI-gedreven zakelijke omgeving en open innovatieve groeipaden
Laten we beginnen!
Wat is MCP en hoe verbindt het AI-tools met je service
MCP (Model Context Protocol) is een open, universeel protocol dat standaardiseert hoe applicaties contextinformatie aan grote taalmodellen (LLMs) geven.
MCP bestaat uit verschillende kerncomponenten die samenwerken om AI-tools toegang te geven tot je services:
In deze gids hoef je alleen te weten dat de MCP-server het belangrijkste verbindingspunt is tussen je service en AI-tools. Het is verantwoordelijk voor het aanbieden van een reeks tools die het LLM kan gebruiken, en deze tools zullen met je eigen services communiceren. Voor meer details over MCP kun je verwijzen naar Wat is MCP (Model Context Protocol) en hoe werkt het. Hier richten we ons alleen op de MCP-server.
We zullen een Content Management Systeem (CMS) gebruiken dat geïntegreerde op rol gebaseerde toegangscontrole (RBAC) beleid heeft als ons voorbeeld. We creëren een MCP-server ervoor en definiëren een get-available-article-count
tool waarmee het LLM het aantal artikelen kan opvragen dat beschikbaar is voor de huidige gebruiker in het CMS:
Dit is de belangrijkste code voor het verbinden van de MCP-server met je service. In deze toolimplementatie stuurt het een verzoek naar de api/articles
eindpunt van de service en geeft het resultaat terug.
Dit is echter verre van voldoende, want de API van je service is mogelijk niet openbaar. Elk eindpunt heeft toegangscontrole nodig en verschillende gebruikers kunnen toegang hebben tot verschillende resources en data.
Dus, als volgende stap, bespreken we hoe we toegangscontrole kunnen toevoegen aan je service.
Hoe toegangscontrole voor de MCP-server te implementeren
Het is belangrijk te begrijpen dat de gebruikers die via AI-tools toegang hebben tot je systeem dezelfde individuen zijn die mogelijk direct je systeem gebruiken - de MCP-server treedt op als hun vertegenwoordiger wanneer ze via AI-tools interageren.
Dus wanneer gebruikers via AI-tools toegang krijgen tot je services, ontstaan er twee praktische toegangscontrole-uitdagingen:
- Hoe meldt de MCP-server zich aan bij je systeem als een gebruiker?
- Moet je systeem zijn hele toegangscontrolemechanisme opnieuw ontwerpen alleen om de MCP-server te accommoderen? Dit zou een significante kosten en inspanning zijn, vooral wanneer je oorspronkelijke systeem al zijn eigen authenticatiemechanisme heeft
De sleutel tot het oplossen van deze problemen is:
Hoe kunnen gebruikers de MCP-server toegang geven vanuit je service zonder hun inloggegevens en interactieve aanmelding te gebruiken?
Als je dit probleem kunt oplossen, kun je direct met je service interageren via de MCP-server, en kan je service blijven gebruikmaken van het eerder ontworpen toegangsmechanisme voor gebruikers, zonder een nieuw systeem te moeten ontwerpen alleen voor de MCP-server!
Maar is dit mogelijk?
Natuurlijk is het dat! We kunnen dit probleem perfect oplossen door gebruik te maken van Persoonlijke Toegangstokens!
Persoonlijke toegangstokens (PATs) bieden een veilige manier voor gebruikers om een toegangstoken te verlenen zonder hun inloggegevens en interactieve aanmelding te gebruiken. Dit is handig voor CI/CD, scripts of applicaties die programmatisch toegang tot resources nodig hebben.
Dit is hoe de workflow eruitziet:
Dus, zolang je systeem Persoonlijke Toegangstokens (PAT) ondersteunt, kun je de toegangscontrole uitdagingen perfect oplossen tussen AI-tools en je bestaande services zonder je authenticatiemechanismen opnieuw te ontwerpen, terwijl je gegevensbeveiliging en privacybescherming voor je gebruikers verzekert.
Nu, laten we zien hoe we dit in praktijk kunnen implementeren.
MCP-server toegangscontrole implementatie
In deze sectie zullen we toegangscontrole implementeren voor een MCP-server met behulp van een bestaand CMS-systeem als onze basis.
Je kunt de complete CMS-demo tutorial en broncode bekijken in RBAC in de praktijk: Implementeren van veilige autorisatie voor je applicatie, maar dit is niet verplicht, we zullen hier alle essentiële principes bespreken.
De CMS-demo is gebaseerd op Logto, een populair open-source identiteitsplatform dat een uitgebreide authenticatie- en autorisatieoplossing biedt, maar de technische implementatie is niet de focus van dit artikel.
Ontwerp permissies en toegangscontrolebeleid voor je service
De eerste stap in het implementeren van toegangscontrole is het ontwerpen van permissies en toegangscontrolebeleid voor je systeem.
In ons CMS-voorbeeld hebben we de volgende API-eindpunten ontworpen op basis van RBAC (Role-Based Access Control) en de vereiste permissies gespecificeerd voor toegang tot elk eindpunt:
Eindpunt | Toegangscontrole-logica |
---|---|
GET /api/articles | - Iedereen met list:articles permissie, OF auteurs kunnen hun eigen artikelen zien |
GET /api/articles/:id | - Iedereen met read:articles permissie, OF auteur van het artikel |
POST /api/articles | - Iedereen met create:articles permissie |
PATCH /api/articles/:id | - Iedereen met update:articles permissie, OF auteur van het artikel |
DELETE /api/articles/:id | - Iedereen met delete:articles permissie, OF auteur van het artikel |
PATCH /api/articles/:id/published | - Alleen gebruikers met publish:articles permissie |
Het permissieontwerp van het systeem is als volgt:
Permissie | Beschrijving |
---|---|
list:articles | Bekijk de lijst met alle artikelen in het systeem |
read:articles | Lees de volledige inhoud van elk artikel |
create:articles | Maak nieuwe artikelen |
update:articles | Wijzig elk artikel |
delete:articles | Verwijder elk artikel |
publish:articles | Verander publicatiestatus |
Op basis van deze permissies hebben we de volgende rollen gedefinieerd voor ons CMS-systeem:
Permissie/Rol | 👑 Admin | 📝 Uitgever | ✍️ Auteur |
---|---|---|---|
Beschrijving | Volledige systeemtoegang voor compleet contentbeheer | Kan alle artikelen bekijken en publicatiestatus beheren | Kan nieuwe artikelen maken in het systeem |
list:articles | ✅ | ✅ | ❌ |
read:articles | ✅ | ✅ | ❌ |
create:articles | ✅ | ❌ | ✅ |
update:articles | ✅ | ❌ | ❌ |
delete:articles | ✅ | ❌ | ❌ |
publish:articles | ✅ | ✅ | ❌ |
Opmerking: Auteurs hebben automatisch lees-/wijzig-/verwijderingsrechten voor hun eigen artikelen, ongeacht rollrechten.
Vervolgens wijzen we rollen toe aan gebruikers in ons systeem (met de CMS-demo als voorbeeld):
Gebruiker | Rol |
---|---|
Alex | Admin |
Bob | Uitgever |
Charlie | Auteur |
En in Logto, zoals vermeld in het RBAC in de praktijk artikel hierboven, hebben we rollen ingesteld voor onze gebruikers.
Pas het toegangscontrolebeleid toe op je service-API
Hier is hoe gebruikers inloggen op onze CMS-demo:
Dus, het toepassen van toegangscontrole op je service-API is net zo eenvoudig als het toevoegen van een middleware om het toegangstoken te valideren en de permissies in stap 9 te controleren.
De kernimplementatie is als volgt (bekijk de complete implementatie in RBAC-voorbeeld - backend):
En pas de middleware toe op de API-eindpunten die authenticatie vereisen:
We hebben nu toegangscontrole toegevoegd aan ons CMS-systeem en rollen toegewezen aan onze gebruikers.
Nadat gebruikers zich aanmelden en hun Toegangstoken voor de CMS-API krijgen, kunnen ze dit token gebruiken om toegang te krijgen tot de CMS-API. Het Toegangstoken bevat de permissie-informatie van de gebruiker. Dit stelt ons in staat om te controleren welke data moet worden teruggegeven op basis van gebruikersrechten.
Onze volgende stap is om de MCP-server te implementeren om Persoonlijke Toegangstokens te gebruiken.
Begrijpen hoe Persoonlijk Toegangstoken gebruikers vertegenwoordigt
Verwijs naar de CMS-authenticatiestroom hierboven, gebruikers krijgen een Toegangstoken voor de CMS-API na het inloggen. Dit Toegangstoken is hun referentie voor toegang tot de CMS-API.
We hoeven alleen een Toegangstoken te krijgen dat vergelijkbaar is met wat gebruikers krijgen na inloggen. Dan kunnen we het gebruiken om toegang te krijgen tot de CMS-API.
Hier komen Persoonlijke Toegangstokens binnen. Ze helpen ons om hetzelfde soort Toegangstoken te krijgen dat gebruikers normaal verkrijgen na het inloggen.
Dit is wat we moeten doen:
- Maak een Persoonlijk Toegangstoken aan voor een gebruiker
- Gebruik dit Persoonlijk Toegangstoken om een uitwisselingstoken op te vragen bij het token-eindpunt van de Auth-service. Dit geeft ons een Toegangstoken zoals gebruikers krijgen na het inloggen
- Gebruik dit Toegangstoken in onze MCP-service tool om toegang te krijgen tot de CMS-API
In dit voorbeeld gebruiken we Logto voor demonstratie, aangezien Logto Persoonlijke Toegangstokens en tokenuitwisseling ondersteunt. Als je Logto niet gebruikt, kun je deze benadering volgen om je eigen ondersteuning voor Persoonlijke Toegangstokens te implementeren.
Maak Persoonlijk Toegangstoken voor je gebruiker
In Logto Console > Gebruikersbeheer kun je een Persoonlijk Toegangstoken voor een gebruiker maken vanuit hun detailpagina:
Bij het maken van een Persoonlijk Toegangstoken kun je de vervaltijd naar wens instellen.
Persoonlijk Toegangstoken gebruiken in MCP-server
Nu we het Persoonlijk Toegangstoken van de gebruiker hebben, kunnen we het in onze MCP-server gebruiken.
Laten we eerst Logto's documentatie over Persoonlijke Toegangstokens volgen, we krijgen een Toegangstoken voor toegang tot de CMS-API van Logto's token-eindpunt. Je kunt de complete broncode hier bekijken hier.
In de MCP-server gebruiken we het Toegangstoken van de exchangeAccessToken
functie om gegevens van de CMS-API op te halen.
Op deze manier hoeft de MCP-server geen gebruikersaanmeldingsgegevens te hebben om toegang te krijgen tot de CMS-API. In plaats daarvan gebruikt het het Persoonlijk Toegangstoken van de gebruiker.
Je kunt de complete code vinden in RBAC-voorbeeld - mcp-server。
Om te leren hoe je deze MCP-server lokaal kunt implementeren met Claude Desktop, bekijk de:MCP Server implementatie gids。
Je kunt deze Server ook implementeren naar verschillende AI IDE's zoals Cursor, Cline, Windsurf, enz.
Test de toegangscontrole
Laten we deze implementatie testen in Claude Desktop.
In ons CMS hebben zowel Alex als Charles elk één artikel gemaakt.
Aangezien Alex de Admin rol heeft, kan hij alle artikelen zien. Charles, als Auteur, kan alleen zijn eigen artikelen zien.
Wanneer we Claude vragen hoeveel beschikbare artikelen er zijn, zal Claude de get-available-article-count
tool gebruiken en om onze toestemming vragen:
Wanneer we Alex's Persoonlijk Toegangstoken gebruiken in MCP en Claude vragen naar het aantal beschikbare artikelen, zal Claude de get-available-article-count
tool aanroepen en ons vertellen dat er 2 artikelen zijn.
Wanneer we overschakelen naar Charles's Persoonlijk Toegangstoken en dezelfde vraag stellen, vertelt Claude ons dat er slechts 1 artikel is.
Geweldig! We hebben Persoonlijke Toegangstokens met succes gebruikt om toegang te krijgen tot de CMS-API en de juiste data op te halen.
Dit is precies wat we wilden: we maken een Persoonlijk Toegangstoken voor elke gebruiker, en wanneer gebruikers hun MCP-server configureren met hun token, creëren we een gepersonaliseerde AI-ervaring voor hen.
Laat me je helpen het Samenvattingsgedeelte te schrijven:
Samenvatting
In deze gids hebben we onderzocht hoe je AI-tools kunt verbinden met je bestaande services terwijl je de juiste toegangscontrole behoudt. We toonden dit aan met behulp van een CMS-systeem met RBAC-implementatie, en lieten zien hoe Persoonlijke Toegangstokens (PATs) elegant de authenticatie-uitdagingen kunnen oplossen.
Je kunt de complete broncode voor deze implementatie vinden in onze RBAC-voorbeelden repository, welke de CMS-backend, frontend en MCP-server implementatie omvat.
Bij het distribueren van je MCP-server naar gebruikers, vergeet niet om het Persoonlijk Toegangstoken configureerbaar te maken. Dit stelt elke gebruiker in staat om:
- Hun eigen PAT in de MCP-server te configureren
- Toegang tot resources te krijgen op basis van hun specifieke permissies
- Gepersonaliseerde AI-ervaringen te krijgen die hun rol en toegangslevels weerspiegelen
Deze benadering zorgt ervoor dat je AI-integratie veilig blijft terwijl je een aangepaste ervaring biedt voor elke gebruiker op basis van hun permissies en rol in je systeem.
Ik wens je enorm veel succes in je bedrijf wanneer je dit AI-integratie avontuur begint! Mogen je services bloeien en groeien met deze nieuwe AI-mogelijkheden! 🚀