Managed AgentsConfiguração empresarial

Single sign-on

Copy page



Permita que pessoas e serviços chamem o seu servidor do Claude Managed Agents auto-hospedado com tokens do seu provedor de identidade.

Por padrão, o seu servidor aceita uma chave compartilhada, a chave de API do servidor. Com single sign-on, cada pessoa ou serviço também pode chamar o servidor com um token do seu provedor de identidade OpenID Connect (OIDC). O servidor atribui ao chamador uma função a partir dos grupos no token. A chave de API do servidor continua funcionando como credencial de administrador.

Esta página mostra como adicionar o seu provedor de identidade, o que cada função pode fazer e como permitir que desenvolvedores façam login a partir de um terminal.

Adicione o seu provedor de identidade

1. 1

   Registre o servidor no seu provedor de identidade

   Registre o servidor como uma API com um identificador como api://cma-server e faça com que os clientes solicitem tokens para ele.

2. 2

   Liste o provedor de identidade no arquivo de configurações

   Adicione uma entrada em auth.issuers no arquivo de configurações:

   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 rotula o emissor nas linhas de log, e o servidor o registra como parte do criador de cada recurso. Não o altere depois que as pessoas tiverem criado recursos.
   • issuer_url precisa ser igual à claim iss dos seus tokens.
   • audiences lista os valores que a claim aud de um token pode conter, como o identificador da primeira etapa.
   • roles mapeia um grupo para admin, developer ou user. A função mais alta correspondente prevalece.

   Para os outros campos, consulte Entradas de emissor. Se o seu provedor for o Microsoft Entra ID, consulte também Microsoft Entra ID.

3. 3

   Reinicie o servidor e verifique o login

   Reinicie o servidor. Um chamador envia o token como Authorization: Bearer <token>, em qualquer rota que aceite a chave de API do servidor.

   Para toda requisição que um token autenticou, o servidor registra em log auth=oidc, o name do emissor e o subject do chamador (sub=).

Se o login falhar

Microsoft Entra ID

O Entra ID difere de outros provedores de duas maneiras. Ambas as configurações ficam na entrada do emissor:

• A pessoa: O Entra ID dá a uma pessoa um sub diferente em cada aplicação cliente, então o padrão registraria uma pessoa como vários criadores. Defina subject_claim: oid.
• Os grupos: O Entra ID deixa a claim groups de fora de um token se a pessoa pertencer a muitos grupos. Essa pessoa então não corresponde a nenhuma entrada de roles. Para evitar isso, faça com que o Entra ID emita apenas os grupos atribuídos à aplicação. Ou atribua funções de aplicativo às pessoas no Entra ID e defina groups_claim: roles para que o servidor leia as funções de aplicativo no lugar dos grupos.

O que cada função pode fazer

developer e user têm o mesmo acesso. Um chamador com qualquer uma dessas funções:

• Não pode ver um recurso que outra pessoa criou. O recurso não aparece nas listas, e uma requisição pelo seu ID recebe a mesma resposta que uma requisição por um ID desconhecido. Isso inclui tudo o que foi criado com a chave de API do servidor antes de você ativar o single sign-on.
• Não pode compartilhar um recurso com outro chamador ou com um grupo.

Mapeie admin para nomes de grupo exatos. Um administrador também pode iniciar uma sessão que usa o vault de qualquer usuário. Então atribua a função apenas a grupos a quem você confiaria os tokens MCP de todos os usuários.

Permita que desenvolvedores façam login a partir de um terminal

Os desenvolvedores podem fazer login pelo seu provedor de identidade e depois usar a CLI ant com a própria identidade, sem a chave de API do servidor. Você executa as duas primeiras etapas, e cada desenvolvedor executa a terceira.

1. 1

   Registre uma aplicação no seu provedor de identidade

   Registre uma aplicação nativa (“pública”) que tenha:

   • Nenhum client secret
   • A concessão de código de autorização com PKCE
   • O URI de redirecionamento http://127.0.0.1/callback

   Alguns provedores precisam de um dos outros URIs de redirecionamento.

2. 2

   Adicione a aplicação à entrada do emissor

   Adicione login_client_id e login_scopes à entrada do emissor e reinicie o servidor:

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

   

   login_scopes lista os escopos de que o seu provedor precisa para emitir um token cuja claim aud esteja na lista audiences da entrada do emissor.

3. 3

   Faça login

   Cada desenvolvedor executa o login a partir do nível superior do arquivo compactado extraído:

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

   

   A URL do servidor precisa ser https://, ou http:// para localhost, 127.0.0.1 ou ::1. Com um dos outros URIs de redirecionamento, adicione a flag correspondente ao comando.

   O comando abre a página de login do provedor em um navegador e depois grava um perfil da CLI ant chamado cma-server. Passe --profile cma-server para qualquer comando ant, ou execute ant profile activate cma-server para tornar o perfil o padrão.

Quando o token expirar, o desenvolvedor executa login novamente. Para que a CLI ant renove o token em vez disso, adicione offline_access a login_scopes.

Outros URIs de redirecionamento

Para listar as outras flags, adicione -h ao comando login.

Permita que as pessoas façam login no console do seu servidor

O console do seu servidor faz o login das pessoas pela aplicação que você registrou para o login pelo terminal. Para concluir a configuração dele, consulte Configurar o login.