Managed AgentsConfiguration d'entreprise

Authentification unique

Copy page



Permettez aux personnes et aux services d’appeler votre serveur Claude Managed Agents auto-hébergé avec des jetons émis par votre fournisseur d’identité.

Par défaut, votre serveur accepte une clé partagée unique, la clé API du serveur. Avec le « single sign-on » (authentification unique), chaque personne ou service peut également appeler le serveur avec un jeton émis par votre fournisseur d’identité OpenID Connect (OIDC). Le serveur attribue un rôle à l’appelant à partir des groupes présents dans le jeton. La clé API du serveur continue de fonctionner comme identifiant d’administrateur.

Cette page explique comment ajouter votre fournisseur d’identité, ce que chaque rôle peut faire et comment permettre aux développeurs de se connecter depuis un terminal.

Ajouter votre fournisseur d’identité

1. 1

   Enregistrer le serveur dans votre fournisseur d’identité

   Enregistrez le serveur comme API avec un identifiant tel que api://cma-server, et faites en sorte que les clients demandent des jetons pour celle-ci.

2. 2

   Lister le fournisseur d’identité dans le fichier de paramètres

   Ajoutez une entrée sous auth.issuers dans le fichier de paramètres :

   auth:
     issuers:
       - name: okta
         issuer_url: https://login.example.com/oauth2/default
         audiences: [api://cma-server]
         roles:
           - group: cma-admins
             role: admin
           - group: "eng-*"
             role: developer

   

   • name identifie l’émetteur dans les lignes de journal, et le serveur l’enregistre comme partie du créateur de chaque ressource. Ne le modifiez pas une fois que des personnes ont créé des ressources.
   • issuer_url doit être égal à la revendication iss de vos jetons.
   • audiences liste les valeurs que la revendication aud d’un jeton peut contenir, comme l’identifiant de la première étape.
   • roles mappe un groupe vers admin, developer ou user. Le rôle le plus élevé parmi les correspondances l’emporte.

   Pour les autres champs, consultez Entrées d’émetteur. Si votre fournisseur est Microsoft Entra ID, consultez également Microsoft Entra ID.

3. 3

   Redémarrer le serveur et vérifier la connexion

   Redémarrez le serveur. Un appelant envoie le jeton sous la forme Authorization: Bearer <token>, sur toute route qui accepte la clé API du serveur.

   Pour chaque requête authentifiée par un jeton, le serveur journalise auth=oidc, le name de l’émetteur et le sujet de l’appelant (sub=).

Si la connexion échoue

Microsoft Entra ID

Entra ID diffère des autres fournisseurs sur deux points. Les deux paramètres se placent dans l’entrée de l’émetteur :

• La personne : Entra ID attribue à une personne un sub différent dans chaque application cliente ; la valeur par défaut enregistrerait donc une même personne comme plusieurs créateurs. Définissez subject_claim: oid.
• Les groupes : Entra ID omet la revendication groups d’un jeton si la personne appartient à de nombreux groupes. Cette personne ne correspond alors à aucune entrée roles. Pour éviter cela, faites en sorte qu’Entra ID n’émette que les groupes attribués à l’application. Ou bien attribuez des rôles d’application aux personnes dans Entra ID, et définissez groups_claim: roles afin que le serveur lise les rôles d’application à la place des groupes.

Ce que chaque rôle peut faire

developer et user disposent du même accès. Un appelant disposant de l’un ou l’autre rôle :

• Ne peut pas voir une ressource créée par quelqu’un d’autre. La ressource est absente des listes, et une requête pour son ID reçoit la même réponse qu’une requête pour un ID inconnu. Cela inclut tout ce qui a été créé avec la clé API du serveur avant que vous n’activiez l’authentification unique.
• Ne peut pas partager une ressource avec un autre appelant ou un groupe.

Mappez admin vers des noms de groupes exacts. Un administrateur peut aussi démarrer une session qui utilise le coffre-fort de n’importe quel utilisateur. N’attribuez donc ce rôle qu’à des groupes auxquels vous confiez les jetons MCP de tous les utilisateurs.

Permettre aux développeurs de se connecter depuis un terminal

Les développeurs peuvent se connecter via votre fournisseur d’identité, puis utiliser la CLI ant sous leur propre identité, sans la clé API du serveur. Vous effectuez les deux premières étapes, et chaque développeur effectue la troisième.

1. 1

   Enregistrer une application dans votre fournisseur d’identité

   Enregistrez une application native (« publique ») qui dispose des éléments suivants :

   • Aucun secret client
   • Le flux d’octroi par code d’autorisation avec PKCE
   • L’URI de redirection http://127.0.0.1/callback

   Certains fournisseurs nécessitent l’une des autres URI de redirection.

2. 2

   Ajouter l’application à l’entrée de l’émetteur

   Ajoutez login_client_id et login_scopes à l’entrée de l’émetteur, puis redémarrez le serveur :

   login_client_id: 0oa1b2c3d4e5f6g7h8i9
   login_scopes: [openid, cma-server.access]

   

   login_scopes liste les scopes dont votre fournisseur a besoin pour émettre un jeton dont la revendication aud figure dans la liste audiences de l’entrée de l’émetteur.

3. 3

   Se connecter

   Chaque développeur exécute la connexion depuis la racine de l’archive extraite :

   ./cma-server-admin login https://cma.example.com

   

   L’URL du serveur doit commencer par https://, ou par http:// vers localhost, 127.0.0.1 ou ::1. Avec l’une des autres URI de redirection, ajoutez son option à la commande.

   La commande ouvre la page de connexion du fournisseur dans un navigateur, puis écrit un profil de la CLI ant nommé cma-server. Passez --profile cma-server à n’importe quelle commande ant, ou exécutez ant profile activate cma-server pour faire de ce profil le profil par défaut.

Lorsque le jeton expire, le développeur exécute à nouveau login. Pour que la CLI ant renouvelle plutôt le jeton, ajoutez offline_access à login_scopes.

Autres URI de redirection

Pour lister les autres options, ajoutez -h à la commande login.

Permettre aux utilisateurs de se connecter à la console de votre serveur

La console de votre serveur connecte les utilisateurs via l’application que vous avez enregistrée pour la connexion depuis le terminal. Pour terminer sa configuration, consultez Configurer la connexion.