Gestionar WIF con la Admin API

La Admin API te permite crear y gestionar recursos de Workload Identity Federation de forma programática: cuentas de servicio, emisores de federación y reglas de federación. Úsala para mantener tu configuración de federación en infraestructura como código, aprovisionarla desde CI y reproducirla en distintas organizaciones en lugar de hacer clic por la Claude Console. Estos endpoints comparten el prefijo de ruta /v1/organizations con el resto de la Admin API.



Requisitos previos

Cada solicitud en esta página se autentica con un "OAuth bearer token" (token de portador OAuth) que incluye el scope org:admin. Este scope se concede únicamente a los miembros de la organización con el rol de admin, owner o primary owner, y otorga acceso a toda la organización: cualquier vinculación a un workspace se ignora. Hay dos formas de obtener un token, y cada una conlleva permisos diferentes: un token obtenido desde tu propio inicio de sesión actúa como un usuario, mientras que un token federado actúa como una cuenta de servicio y no puede realizar todas las operaciones de esta página.

Interactivo (tu terminal): Inicia sesión con la CLI ant bajo un perfil dedicado, solicitando el scope org:admin (consulta Acceso de administrador), y luego exporta el bearer token:

ant auth login --profile admin --scope "org:admin"
export ANTHROPIC_OAUTH_TOKEN=$(ant auth print-credentials --profile admin --access-token)

Los tokens interactivos son de corta duración; si las solicitudes empiezan a devolver 401, vuelve a ejecutar el comando de exportación (actualiza el token automáticamente).

Workload (CI y automatización): Crea una regla de federación con oauth_scope: org:admin que apunte a una cuenta de servicio cuyo organization_role sea admin. La regla en sí debe crearse en la Claude Console: conceder a un workload acceso de administrador de la organización es una acción humana deliberada, no algo que la automatización pueda configurar por sí misma. La siguiente sección te guía por esta configuración que se realiza una sola vez por organización.



Configurar un workload para gestionar WIF

Una sola regla creada en la Console es suficiente para poner el resto de tu configuración de federación bajo infraestructura como código: concede a un único workload de confianza el scope org:admin y deja que ese workload gestione los emisores de federación y todas las reglas de federación con alcance de workspace a través de esta API.

Para conocer las operaciones que un token generado por un workload puede y no puede realizar, consulta Permisos y restricciones. Si ya creaste emisores, cuentas de servicio o reglas con el asistente Connect workload, lístalos con los siguientes endpoints e impórtalos al estado de tu infraestructura como código en lugar de volver a crearlos.



Autenticación

Todos los endpoints se encuentran bajo https://api.anthropic.com/v1/organizations/. Cada solicitud a los endpoints de federación y de cuentas de servicio necesita el encabezado de versión de la API y el bearer token:

curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/service_accounts" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

Las claves de Admin API no se aceptan en estos endpoints; los ejemplos con x-api-key de la página de la Admin API no aplican aquí.



Cuentas de servicio

Una cuenta de servicio (svac_...) es la identidad no humana con la que actúa un token federado. Establece organization_role en developer.

# Crea una cuenta de servicio
curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/service_accounts" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN" \
  --header "content-type: application/json" \
  --data '{
    "name": "inference-worker",
    "organization_role": "developer"
  }'

# Lista las cuentas de servicio
curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/service_accounts?limit=20" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

# Archiva una cuenta de servicio
curl --fail-with-body -sS --request POST "https://api.anthropic.com/v1/organizations/service_accounts/svac_.../archive" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

El endpoint de creación devuelve la nueva cuenta de servicio:

{
  "id": "svac_...",
  "name": "inference-worker",
  "organization_role": "developer",
  "created_at": "...",
  "type": "service_account",
  "...": "..."
}

Para leer o actualizar una sola cuenta de servicio, usa GET y POST en /v1/organizations/service_accounts/{service_account_id}. Una cuenta de servicio debe ser miembro de un workspace antes de que los tokens federados puedan actuar en él. Cada cuenta de servicio tiene una membresía implícita en el workspace predeterminado de tu organización; agrega membresías explícitas para otros workspaces con GET, POST y DELETE en /v1/organizations/service_accounts/{service_account_id}/workspaces, donde DELETE apunta a .../workspaces/{workspace_id}.



Emisores de federación

Un emisor de federación (fdis_...) registra un proveedor de identidad OIDC en tu organización. El campo jwks es una unión discriminada que controla cómo Anthropic obtiene las claves de firma del proveedor:

# Registra un emisor (GitHub Actions, con descubrimiento de JWKS)
curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/federation_issuers" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN" \
  --header "content-type: application/json" \
  --data '{
    "name": "github-actions",
    "issuer_url": "https://token.actions.githubusercontent.com",
    "jwks": {"type": "discovery"}
  }'

# Lista los emisores
curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/federation_issuers?limit=20" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

# Archiva un emisor
curl --fail-with-body -sS --request POST "https://api.anthropic.com/v1/organizations/federation_issuers/fdis_.../archive" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

Para leer o actualizar un solo emisor, usa GET y POST en /v1/organizations/federation_issuers/{issuer_id}. Un llamador OAuth no puede actualizar un emisor que respalde una regla cuyo oauth_scope sea distinto de workspace:developer o workspace:inference; consulta Permisos y restricciones.



Reglas de federación

Una regla de federación (fdrl_...) vincula un emisor a una cuenta de servicio: los JWT del emisor que satisfacen las condiciones de coincidencia de la regla pueden generar tokens que actúan como el destino de la regla. El workspace_id en la solicitud de creación habilita la regla en ese workspace al momento de crearla; agrega más workspaces después a través del sub-recurso /federation_rules/{rule_id}/workspaces. Se requiere workspace_id o applies_to_all_workspaces: true al crear.

# Crea una regla (GitHub Actions despliega desde la rama main)
curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/federation_rules" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN" \
  --header "content-type: application/json" \
  --data '{
    "name": "gha-deploy",
    "issuer_id": "fdis_...",
    "match": {
      "subject_prefix": "repo:my-org/my-repo:ref:refs/heads/main",
      "claims": {"repository_owner": "my-org"}
    },
    "target": {
      "type": "service_account",
      "service_account_id": "svac_..."
    },
    "workspace_id": "wrkspc_...",
    "oauth_scope": "workspace:developer",
    "token_lifetime_seconds": 600
  }'

# Lista las reglas, opcionalmente filtradas por emisor
curl --fail-with-body -sS "https://api.anthropic.com/v1/organizations/federation_rules?issuer_id=fdis_..." \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

# Archiva una regla
curl --fail-with-body -sS --request POST "https://api.anthropic.com/v1/organizations/federation_rules/fdrl_.../archive" \
  --header "anthropic-version: 2023-06-01" \
  --header "authorization: Bearer $ANTHROPIC_OAUTH_TOKEN"

El endpoint de listado devuelve una página de reglas y el cursor para la página siguiente:

{
  "data": [{ "id": "fdrl_...", "name": "gha-deploy", "...": "..." }],
  "next_page": "..."
}

Para leer o actualizar una sola regla, usa GET y POST en /v1/organizations/federation_rules/{rule_id}. Para gestionar los workspaces en los que una regla puede generar tokens, usa GET y POST en /v1/organizations/federation_rules/{rule_id}/workspaces, y DELETE en /v1/organizations/federation_rules/{rule_id}/workspaces/{workspace_id}.



Permisos y restricciones

Una regla con oauth_scope: org:admin debe apuntar a una cuenta de servicio cuyo organization_role sea admin. Los nombres de recursos deben coincidir con ^[a-z0-9-]+$, tener entre 1 y 255 caracteres y ser únicos dentro de una organización para cada tipo de recurso; para conocer las restricciones completas a nivel de campo, consulta Reglas de validación.



Paginación y archivado

Los endpoints de listado de cuentas de servicio, emisores de federación y reglas de federación aceptan limit (de 1 a 100, valor predeterminado 20) y un cursor page tomado de la respuesta anterior. Pasa el valor next_page de la respuesta como el parámetro de consulta page en la siguiente solicitud. El listado del sub-recurso de workspaces de una regla devuelve el conjunto completo sin paginación. Los recursos archivados se ocultan de los listados de forma predeterminada; pasa include_archived=true para incluirlos.

El archivado es una eliminación lógica (soft delete) y es idempotente: archivar un recurso ya archivado se ejecuta correctamente. Archivar un emisor o una cuenta de servicio devuelve 400 mientras una regla de federación activa aún haga referencia a él; archiva primero la regla.



Consulta también

• Workload Identity Federation: conceptos y guía de configuración en la Console
• Referencia de WIF: variables de entorno, reglas de validación, scopes de OAuth y códigos de error
• Admin API: el resto de la superficie de gestión de la organización
• Referencia de la Admin API: esquemas generados de solicitud y respuesta para cada endpoint de la Admin API