delinea-mcp

officiel

Serveur MCP officiel de Delinea pour les API de Delinea Secret Server et de la plateforme

Que pouvez-vous faire avec Delinea MCP ?

  • Rechercher et récupérer des secrets — Utilisez search et fetch pour trouver des secrets et récupérer leurs détails, avec les types d'objets limités par la configuration search_objects et fetch_objects.
  • Gérer les secrets sans exposer les valeurs — Créez ou faites pivoter des mots de passe côté serveur via create_secret_with_generated_password et update_secret_generated_password, en gardant les valeurs des secrets hors du contexte du modèle.
  • Exécuter des rapports SQL — Effectuez des requêtes ad hoc avec run_report ou générez du SQL à partir d'une description en utilisant ai_generate_and_run_report (nécessite Azure OpenAI).
  • Traiter les demandes d'accès et la boîte de réception — Approuvez ou refusez les demandes en attente avec handle_access_request, listez-les via get_pending_access_requests, et gérez les messages de la boîte de réception avec get_inbox_messages et mark_inbox_messages_read.
  • Administrer les utilisateurs, groupes et rôles — Gérez les entités de Secret Server via user_management, group_management, role_management, et les outils de gestion des appartenances associés comme user_role_management et group_role_management.
  • Vérifier la santé du service — Interrogez le point de terminaison de statut de Secret Server avec health_check pour vérifier que le service est opérationnel.

Documentation

DelineaMCP

Serveur MCP pour les API Delinea Secret Server et Platform

License


Actualités

  • 11 août 2026 — Le protocole MCP v2 (révision de spécification 2026-07-28, HTTP streamable) et le support expérimental de l'API StrongDM sont là — voir les notes de version.
  • 11 août 2026 — Nous sommes les fournisseurs d'origine du cas d'utilisation du coffre « aucune visibilité des secrets pour le LLM » — méfiez-vous des imitateurs ;)

Fonctionnalités

  • Authentification automatique auprès de Secret Server
  • Ensemble d'outils Secret Server complet pour gérer les dossiers, les secrets, les utilisateurs, les groupes et les rôles. Comprend des assistants de boîte de réception et de demandes d'accès ainsi que des utilitaires pour agents de codage.
  • Outils de compatibilité ChatGPT (search et fetch) pour des interactions IA contrôlées.
  • Outils optionnels de gestion des utilisateurs Delinea Platform
  • Outils StrongDM (SDM) expérimentaux facultatifs — octrois d'accès, audits d'autorisations, cycle de vie des utilisateurs/rôles, rapports d'état et d'activité (voir docs/strongdm.md ; installer avec pip install "delinea-mcp[strongdm]")
  • Transports HTTP streamable (/mcp), Server-Sent Events (/mcp/sse) hérités et STDIO
  • OAuth 2.0 avec enregistrement dynamique des clients conformément à la spécification MCP
  • Prise en charge de TLS pour les connexions sécurisées
  • Image Docker prête à l'emploi et point d'entrée du serveur de développement
  • Testé avec ChatGPT, Claude Desktop, le connecteur Claude distant, VSCode Copilot et openwebui

Installation

[!NOTE]

Ce projet utilise uv (https://github.com/astral-sh/uv), mais si vous préférez exécuter des commandes sans cela, vous pouvez faire pip et venv comme d'habitude si vous le souhaitez.

  • Installer Uv
  • Initialiser le projet : uv pip sync requirements.txt
  • Utiliser uv run server.py --config config.json

Configuration

Les secrets tels que les mots de passe continuent de provenir des variables d'environnement. Fournissez DELINEA_PASSWORD dans votre environnement shell. Les fonctionnalités optionnelles reposent sur des variables supplémentaires telles que AZURE_OPENAI_KEY ou PLATFORM_SERVICE_PASSWORD.

Les paramètres non secrets appartiennent à config.json :

{
  "delinea_username": "<username>",
  "delinea_base_url": "https://your-secret-server/SecretServer",
  "platform_hostname": "<tenant>.secureplatform.io",
  "platform_service_account": "<service_account>",
  "platform_tenant_id": "<tenant_id>",
  "azure_openai_endpoint": "https://example.openai.azure.com/",
  "azure_openai_deployment": "<deployment_name>",
  "auth_mode": "none",
  "transport_mode": "stdio",
  "chatgpt_disable_scope_checks": false,
  "port": 8000,
  "debug": false,
  "external_hostname": null,
  "ssl_keyfile": null,
  "ssl_certfile": null,
  "registration_psk": null,
  "jwt_key_path": ".cache/jwt.json",
  "oauth_db_path": ".cache/oauth.db",
  "enabled_tools": []
}

Pour Secret Server Cloud, utilisez simplement l'URL cloud sans /SecretServer. Spécifiez ssl_keyfile et ssl_certfile pour activer HTTPS. Pour Let's Encrypt, utilisez les fichiers privkey.pem et fullchain.pem.

Le fichier de configuration prend en charge les clés suivantes :

  • delinea_username - Nom d'utilisateur Secret Server. Doit être un utilisateur programmatique disposant des autorisations nécessaires pour effectuer les tâches souhaitées.
  • delinea_base_url - URL de base de votre instance Secret Server.
  • platform_hostname - Nom d'hôte du tenant Platform (active les outils Platform).
  • platform_service_account - Compte de service utilisé avec l'API Platform.
  • platform_tenant_id - ID du tenant pour les requêtes API Platform.
  • strongdm_api_host - Plan de contrôle StrongDM (par défaut app.strongdm.com:443 ; variantes UK/EU disponibles). Les identifiants proviennent des variables d'environnement SDM_API_ACCESS_KEY / SDM_API_SECRET_KEY ; voir docs/strongdm.md.
  • azure_openai_endpoint - Point de terminaison Azure OpenAI. Uniquement si vous souhaitez la génération automatique de rapports (la plupart des agents peuvent générer leur propre SQL de rapport, ne l'activez donc que si vous en avez besoin).
  • azure_openai_deployment - Nom du déploiement pour Azure OpenAI.
  • auth_mode - Mode d'authentification (none ou oauth). OAuth ne fonctionne évidemment pas avec le transport stdio.
  • transport_mode - stdio pour la ligne de commande ou sse pour HTTP. En mode sse, le serveur expose à la fois le point de terminaison HTTP streamable à /mcp (transport MCP actuel, sert les révisions de protocole 2024-11-05 à 2026-07-28) et les points de terminaison HTTP+SSE hérités à /mcp/sse + /messages/.
  • streamable_http_stateless - par défaut true ; exécuter /mcp sans sessions côté serveur (recommandé pour les connecteurs distants). Définissez false pour activer le fonctionnement par sessions avec le flux GET autonome.
  • streamable_http_json_response - par défaut true ; répondre avec du JSON brut au lieu de réponses tramées SSE sur /mcp.
  • chatgpt_disable_scope_checks - Ignorer la validation de portée sur les requêtes ChatGPT. Activez uniquement si vous rencontrez des problèmes de connexion à ChatGPT.
  • port - Port du serveur HTTP en mode sse.
  • debug - Activer la journalisation détaillée.
  • external_hostname - Nom d'hôte utilisé lors de la construction des audiences de jetons OAuth. N'ajoutez pas de préfixe HTTP(S) ni de port.
  • ssl_keyfile - Chemin vers la clé SSL pour HTTPS. (ex. privkey.pem)
  • ssl_certfile - Chemin vers le certificat SSL pour HTTPS. (ex. fullchain.pem)
  • registration_psk - Clé pré-partagée requise pour enregistrer les clients OAuth. Vous devrez saisir ce secret dans votre navigateur pour approuver les connexions OAuth.
  • jwt_key_path - Emplacement de la paire de clés RSA utilisée pour les jetons OAuth. Par défaut .cache/jwt.json. générée automatiquement si elle n'existe pas.
  • oauth_db_path - Chemin du fichier de base de données OAuth. Par défaut .cache/oauth.db. généré automatiquement s'il n'existe pas.
  • enabled_tools - Liste des noms d'outils à enregistrer. Une liste vide active tous les outils. Il est fortement recommandé d'activer les outils de manière sélective selon le cas d'utilisation ou la tâche. Voir le dossier docs/ pour quelques exemples.
  • search_objects - Types d'objets autorisés pour l'outil search. Par défaut ["secret"] mais peut inclure user, folder, group et role.
  • fetch_objects - Types d'objets autorisés pour l'outil fetch. Par défaut ["secret"] mais peut inclure les mêmes valeurs que search_objects.

Exécution du serveur

Démarrez le serveur localement en mode développement :

python server.py

Au démarrage, le serveur demande un jeton porteur et le stocke pour les requêtes API ultérieures. Ce projet sera étendu pour s'intégrer davantage à l'API Secret Server.

Outils MCP

Le serveur expose des outils MCP pour Secret Server, l'annuaire d'identités Delinea Platform et (optionnellement) StrongDM. Chaque outil publie des annotations de comportement (indicateurs lecture seule/destructifs) via tools/list.

Compatibilité ChatGPT / deep-research

  • search(query) - recherche unifiée renvoyant {id, title, url} résultats ; les types d'objets sont limités par la clé de configuration search_objects (par défaut : secrets uniquement).
  • fetch(id) - récupère un objet unique trouvé par search ; limité par fetch_objects.

Secret Server

  • run_report(sql_query, report_name=None) - crée et exécute un rapport temporaire.
  • ai_generate_and_run_report(description) - génère du SQL à l'aide d'Azure OpenAI et l'exécute. Nécessite les variables Azure OpenAI.
  • list_example_reports() - liste les requêtes d'exemple et les informations sur les tables.
  • get_secret(id, summary=False) - récupère un secret ou des détails récapitulatifs.
  • get_folder(id) - récupère les métadonnées d'un dossier et ses enfants.
  • search_secrets(query, lookup=False) - recherche ou consulte des secrets.
  • search_folders(query, lookup=False) - recherche ou consulte des dossiers.
  • get_secret_environment_variable(secret_id, environment) - génère un script pour récupérer les identifiants d'un secret dans le shell spécifié.
  • check_secret_template(template_id) - récupère les détails du modèle de secret.
  • check_secret_template_field(template_id, field_id) - vérifie si un modèle contient un champ.
  • get_secret_template_field(field_id) - récupère les détails d'un champ de modèle de secret spécifique par ID.
  • handle_access_request(request_id, status, response_comment, start_date=None, expiration_date=None) - approuve ou refuse une demande d'accès.
  • get_pending_access_requests() - liste les demandes d'accès en attente.
  • get_inbox_messages(read_status_filter=None, take=20, skip=0) - récupère les messages de la boîte de réception.
  • mark_inbox_messages_read(message_ids, read=True) - marque les messages comme lus ou non lus.
  • create_secret_with_generated_password(name, secret_template_id, password_field_id, items, folder_id=None, site_id=None, comment=None) - crée un secret dont le mot de passe est généré côté serveur ; seules les métadonnées assainies sont renvoyées, la valeur n'atteint jamais le modèle.
  • update_secret_generated_password(secret_id, field_slug, password_field_id, comment=None) - fait pivoter le mot de passe d'un secret côté serveur sans exposer la valeur.
  • update_secret_fields(secret_id, field_updates, comment=None, allow_password_fields=False) - flux lecture-modèle → mutation des champs non-mots de passe → vérification ; refuse les champs marqués comme mots de passe sauf autorisation explicite.
  • set_secret_field_environment_variable(secret_id, field_slug, environment, source="stdin", comment=None) - génère un script shell (bash/powershell/cmd) qui lit une valeur localement et la pousse dans le champ du secret, de sorte que la valeur contourne entièrement le modèle.
  • bulk_user_response(user_ids, scenario, comment, confirm=False) - combinateur d'incidents pour les opérations groupées sur l'API des utilisateurs. Scénarios : compromise, offboard, unlock, reenable, force_logout ; nécessite confirm=True plus un commentaire d'audit non vide, et affiche un aperçu si non confirmé.
  • role_management(action, role_id=None, data=None, params=None) - gère les rôles. action peut être list, get, create ou update. Passez des paramètres de requête optionnels avec params lors de la liste des rôles. Exemple : role_management("update", role_id=3, data={"name": "New Role"}).
  • user_role_management(action, user_id, role_ids=None) - assigne ou retire des rôles à un utilisateur. action est get, add ou remove et role_ids est une liste d'identifiants de rôles pour les opérations d'ajout/retrait.
  • group_management(action, group_id=None, data=None, params=None) - gère les groupes. action peut être get, list, create ou delete. Fournissez group_id pour get/delete et data lors de la création d'un groupe.
  • folder_management(action, folder_id=None, data=None, params=None) - gère les dossiers. action peut être get, list, create, update ou delete. Fournissez folder_id pour get, update ou delete et fournissez data lors de la création ou de la mise à jour d'un dossier.
  • user_group_management(action, user_id, group_ids=None) - gère l'appartenance aux groupes d'un utilisateur. action est get, add ou remove. Fournissez une liste de group_ids lors de l'ajout ou du retrait d'une appartenance.
  • group_role_management(action, group_id, role_ids=None) - contrôle les rôles sur un groupe. Utilisez les actions list, add ou remove. Fournissez role_ids lors de l'ajout ou du retrait.
  • health_check() - interroge le point de terminaison de vérification d'état de Secret Server et renvoie le statut actuel du service.

Utilisateurs et rôles Delinea Platform

Depuis la v1.0.0, les outils canoniques pour les utilisateurs ciblent l'annuaire d'identités Delinea Platform (nécessite les identifiants platform_hostname + PLATFORM_SERVICE_* ; sans eux, les outils renvoient des conseils au lieu d'échouer) :

  • user_management(action, user_id=None, data=None, username=None) - CRUD utilisateurs Platform. action accepte get, create, update, delete ou search.
  • search_users(query) - recherche dans l'annuaire d'utilisateurs Platform.
  • platform_role_management(action, role_id=None, data=None, page_size=100, query="%") - CRUD rôles Platform (list, get, create, update, delete) ; les mutations de rôles sont pilotées par la découverte et renvoient des conseils pour les tenants dont la portée API ne les expose pas.
  • platform_user_role_management(action, role_id, user_principals=None) - list, add ou remove des utilisateurs sur un rôle Platform.
  • platform_user_management(...) - alias obsolète de user_management.

Utilisateurs locaux Secret Server (hérité)

Pour les déploiements SS uniquement sans Platform configurée :

  • secretserver_local_user_management(action, user_id=None, data=None, skip=0, take=20, is_exporting=False) - les opérations utilisateur Secret Server d'avant la v1.0.0 : get, create, update, delete, list_sessions, reset_2fa, reset_password, lock_out. Exemple : secretserver_local_user_management("reset_password", user_id=42, data={"newPassword": "Pa$$w0rd"}).
  • search_secretserver_local_users(query) - recherche dans le magasin d'utilisateurs locaux de Secret Server.

Outils StrongDM (facultatifs, expérimentaux)

Expérimental : le backend StrongDM n'a pas encore été vérifié contre une organisation SDM en production (testé uniquement contre la surface SDK). Attendez-vous à des imperfections et signalez les problèmes. Installé via l'extra strongdm ; voir docs/strongdm.md pour le guide complet. sdm_search, sdm_audit_access, sdm_grant_access (octrois limités dans le temps just-in-time ou permanents), sdm_revoke_access, sdm_user_management (flux d'intégration/désintégration), sdm_role_management, sdm_resource_health, sdm_access_requests, sdm_activity_report, sdm_network_status. Les actions destructives sont conditionnées à une confirmation avec commentaires d'audit ; les correspondances de noms ambiguës renvoient des candidats sans mutation.

Utilisez les variables de configuration du serveur décrites ci-dessus pour vous authentifier. L'outil IA est automatiquement désactivé si les variables Azure OpenAI sont manquantes. Seuls les noms d'outils listés dans config.json seront enregistrés. Une liste vide active tous les outils.

Cas d'utilisation

La documentation couvre plusieurs flux de travail pour connecter des outils au serveur :

Démarrage rapide avec Docker

Un Dockerfile est fourni pour exécuter le serveur MCP sans installer les dépendances Python localement.

  1. Construire l'image :
docker build -t dev.local/delinea-mcp:latest .
  1. Exécuter le serveur (transmettez vos identifiants via des variables d'environnement) :
docker run --rm -p 8000:8000 \
  -e DELINEA_PASSWORD=<password> \
  -e PLATFORM_SERVICE_PASSWORD=<password> \
  -e DELINEA_DEBUG=1 \
  -e AZURE_OPENAI_KEY=<your-key-or-appropriate-token> \
  -v $(pwd)/config.json:/app/config.json:ro \
  -v mcp-data:/app/data \
  dev.local/delinea-mcp:latest

Renseignez config.json avec vos noms d'utilisateur et vos URL comme indiqué ci-dessus.

Le conteneur stocke oauth.db et jwt.json dans /app/data. Montez un volume (représenté par mcp-data ci-dessus) afin que ces fichiers et tout certificat HTTPS persistent entre les exécutions.

Remplacez <https://your-secret-server/SecretServer> par l'URL de base de votre instance Secret Server pour éviter les erreurs de connexion.

Le serveur démarrera sur le port 8000 par défaut en utilisant python server.py. Définissez l'option port dans config.json pour remplacer la valeur par défaut. Activez debug: true pour journaliser toutes les requêtes HTTP entrantes.

Exemples de scripts

Le script manual_secret_request.py montre comment récupérer un jeton OAuth pour un ID de secret spécifique :

python scripts/manual_secret_request.py <Secret_ID>

Définissez les variables d'environnement SECRET_USERNAME_<id> et SECRET_PASSWORD_<id> pour le secret avant d'exécuter le script. Définissez éventuellement DELINEA_BASE_URL pour remplacer le https://localhost/SecretServer par défaut.

Exécution des tests

Exécutez les tests unitaires avec couverture (l'IC exige un minimum de 70 %) :

pip install -r requirements.txt
coverage run -m pytest -q
coverage report --omit "tests/*"

Tests en direct

Certains tests d'intégration nécessitent des identifiants valides. Définissez les variables d'environnement suivantes ainsi que le LIVE_SECRET_ID facultatif avant d'exécuter la suite :

export DELINEA_PASSWORD=<password>
# Optional secret used by tests/test_live.py
export LIVE_SECRET_ID=<id>
export SECRET_USERNAME_<id>=<secret_username>
export SECRET_PASSWORD_<id>=<secret_password>

Lorsque ces variables sont présentes, les tests en direct effectuent de véritables requêtes API.

Déploiement en production

Les dépendances sont épinglées dans requirements.txt et les versions sont étiquetées selon le Semantic Versioning. Construisez l'image Docker à partir d'un commit étiqueté et déployez-la dans votre environnement de production, en transmettant les variables d'environnement requises (DELINEA_USERNAME, DELINEA_PASSWORD, éventuellement DELINEA_BASE_URL). Les fonctionnalités optionnelles reposent sur des variables supplémentaires :

  • PLATFORM_SERVICE_PASSWORD avec PLATFORM_HOSTNAME, PLATFORM_SERVICE_ACCOUNT et PLATFORM_TENANT_ID active les outils de gestion des utilisateurs.
  • AZURE_OPENAI_KEY avec AZURE_OPENAI_ENDPOINT et AZURE_OPENAI_DEPLOYMENT active l'assistant de génération de rapports IA.
  • SDM_API_ACCESS_KEY et SDM_API_SECRET_KEY activent les outils expérimentaux StrongDM (nécessite l'extension strongdm ; voir docs/strongdm.md).

Lors d'une exécution avec le transport OAuth ou SSE, vous devrez peut-être fournir registration_psk et configurer un external_hostname ou des fichiers de certificat HTTPS.

Structure du dépôt

  • delinea_mcp/ - package contenant les outils MCP : tools.py (Secret Server), user_platform_tools.py (Delinea Platform), secretserver_users.py (utilisateurs locaux SS), strongdm_tools.py (StrongDM, facultatif), plus transports/ (SSE + HTTP streamable) et auth/ (le serveur d'autorisation OAuth intégré).
  • server.py - point d'entrée léger qui enregistre tout auprès du serveur MCP.
  • docs/ - documentation du projet et le delinea-secret-server-openapi-spec.json généré.
  • scripts/ - exemples d'aide, y compris manual_secret_request.py.

Considérations de sécurité

Le serveur d'autorisation OAuth intégré est une commodité pour le développement, les tests et les petits déploiements ; les déploiements plus importants doivent placer le serveur derrière le fournisseur d'identité de leur organisation. Mesures de protection actuelles :

  • L'enregistrement du client (/oauth/register) et le formulaire d'autorisation exigent tous deux le secret partagé registration_psk (comparé à temps constant).
  • Les valeurs redirect_uri sont validées par rapport aux URI enregistrés pour le client à la fois sur le formulaire d'autorisation et sur la redirection du code.
  • Les jetons d'accès sont des JWT RS256 liés à l'audience ; la découverte des ressources suit la RFC 9728 (/.well-known/oauth-protected-resource plus en-têtes WWW-Authenticate sur les réponses 401/403).
  • Déployez toujours avec TLS (ssl_keyfile/ssl_certfile ou un proxy de terminaison) — les jetons porteurs et les secrets transitent à chaque requête.
  • Limitez l'exposition des outils selon le cas d'usage avec enabled_tools ; les valeurs des secrets sont exclues du contexte du modèle par conception (génération de mots de passe côté serveur, indirection de script par variables d'environnement, protections des champs de mot de passe).

Notes de version

Consultez CHANGELOG.md pour un résumé des dernières fonctionnalités et des éléments de la feuille de route.

Feuille de route

  1. Authentification par transit
  2. Prise en charge des clients OAuth Client ID Metadata Documents (CIMD) (l'enregistrement dynamique des clients est obsolète depuis la révision 2026-07-28 du protocole MCP ; le flux /oauth/register protégé par PSK continue de fonctionner pour les connecteurs actuels)
  3. Étendre la couverture des outils sur la Delinea Platform et ajouter d'autres produits Delinea

Contribution

Les contributions sont les bienvenues ! Veuillez ouvrir des issues ou des pull requests pour toute amélioration. Tout nouveau code doit inclure des tests unitaires et réussir la suite de tests existante.

Licence

Ce projet est sous licence MIT License.