Managed AgentsConfiguración empresarial

Inicio de sesión único

Copy page



Permite que personas y servicios llamen a tu servidor de Claude Managed Agents autoalojado con tokens de tu proveedor de identidad.

De forma predeterminada, tu servidor acepta una clave compartida, la clave de API del servidor. Con el inicio de sesión único, cada persona o servicio también puede llamar al servidor con un token de tu proveedor de identidad OpenID Connect (OIDC). El servidor asigna al llamante un rol a partir de los grupos del token. La clave de API del servidor sigue funcionando como credencial de administrador.

Esta página muestra cómo agregar tu proveedor de identidad, qué puede hacer cada rol y cómo permitir que los desarrolladores inicien sesión desde una terminal.

Agregar tu proveedor de identidad

1. 1

   Registra el servidor en tu proveedor de identidad

   Registra el servidor como una API con un identificador como api://cma-server, y haz que los clientes soliciten tokens para ella.

2. 2

   Indica el proveedor de identidad en el archivo de configuración

   Agrega una entrada en auth.issuers en el archivo de configuración:

   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 etiqueta al emisor en las líneas del registro, y el servidor lo registra como parte del creador de cada recurso. No lo cambies una vez que las personas hayan creado recursos.
   • issuer_url debe ser igual a la afirmación iss de tus tokens.
   • audiences enumera los valores que puede llevar la afirmación aud de un token, como el identificador del primer paso.
   • roles asigna un grupo a admin, developer o user. Gana el rol coincidente más alto.

   Para los demás campos, consulta Entradas de emisor. Si tu proveedor es Microsoft Entra ID, consulta también Microsoft Entra ID.

3. 3

   Reinicia el servidor y comprueba el inicio de sesión

   Reinicia el servidor. Un llamante envía el token como Authorization: Bearer <token>, en cualquier ruta que acepte la clave de API del servidor.

   Para cada solicitud que autenticó un token, el servidor registra auth=oidc, el name del emisor y el sujeto del llamante (sub=).

Si el inicio de sesión falla

Microsoft Entra ID

Entra ID se diferencia de otros proveedores en dos aspectos. Ambos ajustes van en la entrada del emisor:

• La persona: Entra ID asigna a una persona un sub diferente en cada aplicación cliente, así que el valor predeterminado registraría a una misma persona como varios creadores. Establece subject_claim: oid.
• Los grupos: Entra ID omite la afirmación groups de un token si la persona pertenece a muchos grupos. Entonces esa persona no coincide con ninguna entrada de roles. Para evitarlo, haz que Entra ID emita solo los grupos asignados a la aplicación. O asigna roles de aplicación a las personas en Entra ID y establece groups_claim: roles para que el servidor lea los roles de aplicación en lugar de los grupos.

Qué puede hacer cada rol

developer y user tienen el mismo acceso. Un llamante con cualquiera de estos roles:

• No puede ver un recurso que creó otra persona. El recurso no aparece en las listas, y una solicitud de su ID recibe la misma respuesta que una solicitud de un ID desconocido. Eso incluye todo lo creado con la clave de API del servidor antes de que activaras el inicio de sesión único.
• No puede compartir un recurso con otro llamante ni con un grupo.

Asigna admin a nombres de grupo exactos. Un administrador también puede iniciar una sesión que use el vault de cualquier usuario. Así que otorga el rol solo a grupos a los que confiarías los tokens de MCP de todos los usuarios.

Permitir que los desarrolladores inicien sesión desde una terminal

Los desarrolladores pueden iniciar sesión a través de tu proveedor de identidad y luego usar la CLI ant con su propia identidad, sin la clave de API del servidor. Tú haces los dos primeros pasos, y cada desarrollador hace el tercero.

1. 1

   Registra una aplicación en tu proveedor de identidad

   Registra una aplicación nativa (“pública”) que tenga:

   • Ningún secreto de cliente
   • La concesión de código de autorización con PKCE
   • El URI de redirección http://127.0.0.1/callback

   Algunos proveedores necesitan uno de los otros URI de redirección.

2. 2

   Agrega la aplicación a la entrada del emisor

   Agrega login_client_id y login_scopes a la entrada del emisor y reinicia el servidor:

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

   

   login_scopes enumera los ámbitos que tu proveedor necesita para emitir un token cuya afirmación aud esté en la lista audiences de la entrada del emisor.

3. 3

   Inicia sesión

   Cada desarrollador ejecuta el inicio de sesión desde la raíz del archivo de la versión extraído:

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

   

   La URL del servidor debe ser https://, o http:// hacia localhost, 127.0.0.1 o ::1. Con uno de los otros URI de redirección, agrega su flag al comando.

   El comando abre la página de inicio de sesión del proveedor en un navegador y luego escribe un perfil de la CLI ant llamado cma-server. Pasa --profile cma-server a cualquier comando ant, o ejecuta ant profile activate cma-server para que el perfil sea el predeterminado.

Cuando el token caduca, el desarrollador vuelve a ejecutar login. Para que la CLI ant renueve el token en su lugar, agrega offline_access a login_scopes.

Otros URI de redirección

Para enumerar las demás flags, agrega -h al comando login.

Permitir que las personas inicien sesión en la consola de tu servidor

La consola de tu servidor inicia la sesión de las personas a través de la aplicación que registraste para el inicio de sesión desde la terminal. Para terminar su configuración, consulta Configurar el inicio de sesión.