Managed AgentsKonfiguration für Unternehmen

Single Sign-on

Copy page



Lass Personen und Dienste deinen selbst gehosteten Claude Managed Agents-Server mit Tokens von deinem Identitätsanbieter aufrufen.

Standardmäßig akzeptiert dein Server einen gemeinsamen Schlüssel, den Server-API-Key. Mit Single Sign-on kann jede Person oder jeder Dienst den Server zusätzlich mit einem Token von deinem OpenID Connect (OIDC)-Identitätsanbieter aufrufen. Der Server weist dem Aufrufer anhand der Gruppen im Token eine Rolle zu. Der Server-API-Key funktioniert weiterhin als Administrator-Anmeldedaten.

Diese Seite zeigt, wie du deinen Identitätsanbieter hinzufügst, was jede Rolle tun kann und wie du Entwicklern die Anmeldung über ein Terminal ermöglichst.

Deinen Identitätsanbieter hinzufügen

1. 1

   Den Server in deinem Identitätsanbieter registrieren

   Registriere den Server als API mit einem Bezeichner wie api://cma-server und lass Clients Tokens dafür anfordern.

2. 2

   Den Identitätsanbieter in der Einstellungsdatei auflisten

   Füge einen Eintrag unter auth.issuers in der Einstellungsdatei hinzu:

   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 kennzeichnet den Aussteller in Log-Zeilen, und der Server speichert ihn als Teil des Erstellers jeder Ressource. Ändere ihn nicht mehr, sobald Personen Ressourcen erstellt haben.
   • issuer_url muss dem iss-Claim deiner Tokens entsprechen.
   • audiences listet die Werte auf, die der aud-Claim eines Tokens enthalten kann, etwa den Bezeichner aus dem ersten Schritt.
   • roles ordnet einer Gruppe admin, developer oder user zu. Die höchste passende Rolle gewinnt.

   Die übrigen Felder findest du unter Aussteller-Einträge. Wenn dein Anbieter Microsoft Entra ID ist, siehe außerdem Microsoft Entra ID.

3. 3

   Den Server neu starten und die Anmeldung prüfen

   Starte den Server neu. Ein Aufrufer sendet das Token als Authorization: Bearer <token>, auf jeder Route, die den Server-API-Key akzeptiert.

   Für jede Anfrage, die ein Token authentifiziert hat, protokolliert der Server auth=oidc, den name des Ausstellers und das Subject des Aufrufers (sub=).

Wenn die Anmeldung fehlschlägt

Microsoft Entra ID

Entra ID unterscheidet sich in zwei Punkten von anderen Anbietern. Beide Einstellungen gehören in den Aussteller-Eintrag:

• Die Person: Entra ID gibt einer Person in jeder Client-Anwendung ein anderes sub, sodass der Standard eine Person als mehrere Ersteller speichern würde. Setze subject_claim: oid.
• Die Gruppen: Entra ID lässt den groups-Claim in einem Token weg, wenn die Person vielen Gruppen angehört. Diese Person passt dann zu keinem roles-Eintrag. Um das zu verhindern, lass Entra ID nur die Gruppen ausgeben, die der Anwendung zugewiesen sind. Oder weise Personen in Entra ID App-Rollen zu und setze groups_claim: roles, damit der Server App-Rollen anstelle von Gruppen liest.

Was jede Rolle tun kann

developer und user haben denselben Zugriff. Ein Aufrufer mit einer dieser Rollen:

• Kann keine Ressource sehen, die jemand anderes erstellt hat. Die Ressource fehlt in Listen, und eine Anfrage nach ihrer ID erhält dieselbe Antwort wie eine Anfrage nach einer unbekannten ID. Das schließt alles ein, was mit dem Server-API-Key erstellt wurde, bevor du Single Sign-on aktiviert hast.
• Kann eine Ressource nicht teilen, weder mit einem anderen Aufrufer noch mit einer Gruppe.

Ordne admin exakten Gruppennamen zu. Ein Administrator kann außerdem eine Sitzung starten, die den Vault eines beliebigen Benutzers verwendet. Weise die Rolle also nur Gruppen zu, denen du die MCP-Tokens aller Benutzer anvertraust.

Entwicklern die Anmeldung über ein Terminal ermöglichen

Entwickler können sich über deinen Identitätsanbieter anmelden und dann die ant CLI unter ihrer eigenen Identität verwenden, ohne den Server-API-Key. Die ersten beiden Schritte erledigst du, den dritten jeder Entwickler.

1. 1

   Eine Anwendung in deinem Identitätsanbieter registrieren

   Registriere eine native („öffentliche“) Anwendung mit diesen Eigenschaften:

   • Kein Client-Secret
   • Authorization Code Grant mit PKCE
   • Redirect-URI http://127.0.0.1/callback

   Manche Anbieter benötigen eine der anderen Redirect-URIs.

2. 2

   Die Anwendung zum Aussteller-Eintrag hinzufügen

   Füge login_client_id und login_scopes zum Aussteller-Eintrag hinzu und starte den Server neu:

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

   

   login_scopes listet die Scopes auf, die dein Anbieter benötigt, um ein Token auszustellen, dessen aud-Claim in der audiences-Liste des Aussteller-Eintrags steht.

3. 3

   Anmelden

   Jeder Entwickler führt die Anmeldung von der obersten Ebene des entpackten Archivs aus:

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

   

   Die URL des Servers muss mit https:// beginnen oder mit http:// auf localhost, 127.0.0.1 oder ::1 verweisen. Bei einer der anderen Redirect-URIs füge ihr Flag zum Befehl hinzu.

   Der Befehl öffnet die Anmeldeseite des Anbieters in einem Browser und schreibt dann ein ant CLI-Profil namens cma-server. Übergib --profile cma-server an einen beliebigen ant-Befehl oder führe ant profile activate cma-server aus, um das Profil zum Standard zu machen.

Wenn das Token abläuft, führt der Entwickler login erneut aus. Damit die ant CLI das Token stattdessen erneuert, füge offline_access zu login_scopes hinzu.

Andere Redirect-URIs

Um die anderen Flags aufzulisten, füge -h zum login-Befehl hinzu.

Personen die Anmeldung an der Konsole auf deinem Server ermöglichen

Die Konsole auf deinem Server meldet Personen über die Anwendung an, die du für die Terminal-Anmeldung registriert hast. Um ihre Einrichtung abzuschließen, siehe Anmeldung einrichten.