Claude Platform Docs
Managed Agentsエンタープライズ設定

シングルサインオン

ユーザーやサービスが、IDプロバイダーのトークンを使ってセルフホスト型Claude Managed Agentsサーバーを呼び出せるようにします。

デフォルトでは、サーバーは1つの共有キーであるサーバーAPIキーを受け付けます。「single sign-on」（シングルサインオン）では、各ユーザーやサービスは「OpenID Connect」、すなわちOIDCのIDプロバイダーから取得したトークンでもサーバーを呼び出せます。サーバーは、トークン内のグループに基づいて呼び出し元にロールを付与します。サーバーAPIキーは管理者の認証情報として引き続き機能します。

このページでは、IDプロバイダーを追加する方法、各ロールでできること、および開発者がターミナルからログインできるようにする方法を示します。

IDプロバイダーを追加する

  1. IDプロバイダーにサーバーを登録する

    api://cma-serverなどの識別子を持つAPIとしてサーバーを登録し、クライアントにそのトークンを要求させます。

  2. 設定ファイルにIDプロバイダーを列挙する

    設定ファイルのauth.issuersの下にエントリを追加します。

    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はログ行で発行者を識別するラベルであり、サーバーはこれを各リソースの作成者の一部として記録します。ユーザーがリソースを作成した後は変更しないでください。
    • issuer_urlはトークンのissクレームと一致する必要があります。
    • audiencesは、最初のステップで設定した識別子など、トークンのaudクレームが持つことのできる値を列挙します。
    • rolesは、グループをadmin、developer、またはuserにマッピングします。一致したロールのうち最も高いものが適用されます。

    その他のフィールドについては、発行者エントリを参照してください。プロバイダーがMicrosoft Entra IDの場合は、Microsoft Entra IDも参照してください。

  3. サーバーを再起動してサインインを確認する

    サーバーを再起動します。呼び出し元は、サーバーAPIキーを受け付ける任意のルートで、トークンをAuthorization: Bearer <token>として送信します。

    トークンで認証されたすべてのリクエストについて、サーバーはauth=oidc、発行者のname、および呼び出し元のサブジェクト（sub=）をログに記録します。

サインインが失敗した場合

レスポンス原因サーバーのログ行に含まれる内容
401（誤ったAPIキーの場合と同じ）トークンがチェックに失敗しました。理由はログ行に記録されます。oidc token
403トークンのグループがどのrolesエントリにも一致しませんtoken holds no role

Microsoft Entra ID

Entra IDは、次の2点で他のプロバイダーと異なります。どちらの設定も発行者エントリに記述します。

  • ユーザー： Entra IDはクライアントアプリケーションごとに異なるsubをユーザーに付与するため、デフォルトでは1人のユーザーが複数の作成者として記録されてしまいます。subject_claim: oidを設定してください。
  • グループ： ユーザーが多数のグループに所属している場合、Entra IDはトークンからgroupsクレームを省略します。その場合、そのユーザーはどのrolesエントリにも一致しなくなります。これを防ぐには、アプリケーションに割り当てられたグループのみをEntra IDに出力させてください。または、Entra IDでユーザーにアプリロールを割り当て、groups_claim: rolesを設定して、サーバーがグループの代わりにアプリロールを読み取るようにしてください。

各ロールでできること

ロールエージェント、スキル、セッション、ボールト、メモリストア環境
admin、およびサーバーAPIキーすべてを参照・変更できる作成、変更、削除、およびキーの作成ができる
developerまたはuserその呼び出し元が作成したもののみ参照・変更できる一覧表示、読み取り、およびセッションの実行ができる

developerとuserのアクセス権は同じです。いずれかのロールを持つ呼び出し元は、次のようになります。

  • 他の誰かが作成したリソースを参照できません。 そのリソースはリストに表示されず、そのIDに対するリクエストは不明なIDに対するリクエストと同じ応答を受け取ります。これには、シングルサインオンを有効にする前にサーバーAPIキーで作成されたすべてのものが含まれます。
  • リソースを共有できません（他の呼び出し元やグループとの共有）。

adminは正確なグループ名にマッピングしてください。管理者は任意のユーザーのボールトを使用するセッションを開始することもできます。そのため、このロールは全ユーザーのMCPトークンを任せられるグループにのみ付与してください。

開発者がターミナルからログインできるようにする

開発者は、IDプロバイダー経由でログインし、サーバーAPIキーを使わずに自身のIDでant CLIを使用できます。最初の2つのステップは管理者が行い、3つ目のステップは各開発者が行います。

  1. IDプロバイダーにアプリケーションを登録する

    次の条件を持つネイティブ（「パブリック」）アプリケーションを登録します。

    • クライアントシークレットなし
    • PKCE付きの認可コードグラント
    • リダイレクトURIhttp://127.0.0.1/callback

    一部のプロバイダーでは、その他のリダイレクトURIのいずれかが必要です。

  2. 発行者エントリにアプリケーションを追加する

    発行者エントリにlogin_client_idとlogin_scopesを追加して、サーバーを再起動します。

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

    login_scopesには、audクレームが発行者エントリのaudiencesリストに含まれるトークンを発行するためにプロバイダーが必要とするスコープを列挙します。

  3. ログインする

    各開発者は、展開したアーカイブの最上位からログインを実行します。

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

    サーバーのURLはhttps://であるか、localhost、127.0.0.1、または::1へのhttp://である必要があります。その他のリダイレクトURIのいずれかを使用する場合は、そのフラグをコマンドに追加します。

    このコマンドはブラウザでプロバイダーのサインインページを開き、その後cma-serverという名前のant CLIプロファイルを書き込みます。任意のantコマンドに--profile cma-serverを渡すか、ant profile activate cma-serverを実行してそのプロファイルをデフォルトにします。

トークンの有効期限が切れたら、開発者は再度loginを実行します。代わりにant CLIにトークンを更新させるには、login_scopesにoffline_accessを追加します。

その他のリダイレクトURI

プロバイダー登録するリダイレクトURI開発者がloginコマンドに追加するフラグ
Microsoft Entra IDhttp://localhost/callback-listen localhost:0
リダイレクトURIにポートを必要とするものhttp://127.0.0.1:8123/callbackのような固定ポートを持つURI-listen 127.0.0.1:8123

その他のフラグを一覧表示するには、loginコマンドに-hを追加します。

サーバー上のコンソールにユーザーがサインインできるようにする

サーバー上のコンソールは、ターミナルログイン用に登録したアプリケーションを通じてユーザーをサインインさせます。セットアップを完了するには、サインインを設定するを参照してください。

このページは役に立ちましたか？