Gérer WIF avec l'Admin API

L'Admin API vous permet de créer et de gérer des ressources de Workload Identity Federation de manière programmatique : comptes de service, émetteurs de fédération et règles de fédération. Utilisez-la pour conserver votre configuration de fédération dans l'infrastructure as code, la provisionner depuis la CI et la reproduire dans plusieurs organisations au lieu de cliquer dans la Claude Console. Ces points de terminaison partagent le préfixe de chemin /v1/organizations avec le reste de l'Admin API.



Prérequis

Chaque requête de cette page s'authentifie avec un jeton porteur OAuth qui porte le scope org:admin. Ce scope n'est accordé qu'aux membres de l'organisation ayant le rôle admin, owner ou primary owner, et il donne accès à l'ensemble de l'organisation : toute liaison à un workspace est ignorée. Il existe deux façons d'obtenir un jeton, et elles confèrent des permissions différentes : un jeton issu de votre propre connexion agit en tant qu'utilisateur, tandis qu'un jeton fédéré agit en tant que compte de service et ne peut pas effectuer toutes les opérations décrites sur cette page.

Interactif (votre terminal) : Connectez-vous avec la CLI ant sous un profil dédié, en demandant le scope org:admin (voir Accès administrateur), puis exportez le jeton porteur :

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

Les jetons interactifs ont une durée de vie courte ; si les requêtes commencent à renvoyer 401, réexécutez la commande d'exportation (elle actualise automatiquement le jeton).

Workload (CI et automatisation) : Créez une règle de fédération avec oauth_scope: org:admin qui cible un compte de service dont le organization_role est admin. La règle elle-même doit être créée dans la Claude Console : accorder à un workload un accès administrateur d'organisation est une action humaine délibérée, et non quelque chose que l'automatisation peut amorcer elle-même. La section suivante décrit cette configuration à effectuer une seule fois par organisation.



Amorcer un workload pour gérer WIF

Une seule règle créée dans la Console suffit pour placer le reste de votre configuration de fédération sous infrastructure as code : accordez le scope org:admin à un seul workload de confiance, et laissez ce workload gérer les émetteurs de fédération et toutes les règles de fédération à portée de workspace via cette API.

Pour les opérations qu'un jeton généré par un workload peut et ne peut pas effectuer, voir Permissions et contraintes. Si vous avez déjà créé des émetteurs, des comptes de service ou des règles avec l'assistant Connect workload, listez-les avec les points de terminaison suivants et importez-les dans l'état de votre infrastructure-as-code au lieu de les recréer.



Authentification

Tous les points de terminaison se trouvent sous https://api.anthropic.com/v1/organizations/. Chaque requête vers les points de terminaison de fédération et de compte de service nécessite l'en-tête de version de l'API et le jeton porteur :

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"

Les clés Admin API ne sont pas acceptées sur ces points de terminaison ; les exemples x-api-key de la page Admin API ne s'appliquent pas ici.



Comptes de service

Un compte de service (svac_...) est l'identité non humaine sous laquelle agit un jeton fédéré. Définissez organization_role sur developer.

# Créer un compte de service
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"
  }'

# Lister les comptes de service
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"

# Archiver un compte de service
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"

Le point de terminaison de création renvoie le nouveau compte de service :

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

Pour lire ou mettre à jour un compte de service unique, utilisez GET et POST sur /v1/organizations/service_accounts/{service_account_id}. Un compte de service doit être membre d'un workspace avant que les jetons fédérés puissent y agir. Chaque compte de service possède une appartenance implicite au workspace par défaut de votre organisation ; ajoutez des appartenances explicites pour d'autres workspaces avec GET, POST et DELETE sur /v1/organizations/service_accounts/{service_account_id}/workspaces, où DELETE cible .../workspaces/{workspace_id}.



Émetteurs de fédération

Un émetteur de fédération (fdis_...) enregistre un fournisseur d'identité OIDC auprès de votre organisation. Le champ jwks est une union discriminée qui contrôle la manière dont Anthropic récupère les clés de signature du fournisseur :

# Enregistrer un émetteur (GitHub Actions, avec découverte 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"}
  }'

# Lister les émetteurs
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"

# Archiver un émetteur
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"

Pour lire ou mettre à jour un émetteur unique, utilisez GET et POST sur /v1/organizations/federation_issuers/{issuer_id}. Un appelant OAuth ne peut pas mettre à jour un émetteur qui sous-tend une règle dont le oauth_scope est autre que workspace:developer ou workspace:inference ; voir Permissions et contraintes.



Règles de fédération

Une règle de fédération (fdrl_...) lie un émetteur à un compte de service : les JWT de l'émetteur qui satisfont aux conditions de correspondance de la règle peuvent générer des jetons qui agissent en tant que cible de la règle. Le workspace_id dans la requête de création active la règle dans ce workspace à la création ; ajoutez d'autres workspaces ultérieurement via la sous-ressource /federation_rules/{rule_id}/workspaces. Soit workspace_id, soit applies_to_all_workspaces: true est requis à la création.

# Créer une règle (GitHub Actions déploie depuis la branche 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
  }'

# Lister les règles, éventuellement filtrées par émetteur
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"

# Archiver une règle
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"

Le point de terminaison de liste renvoie une page de règles et le curseur pour la page suivante :

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

Pour lire ou mettre à jour une règle unique, utilisez GET et POST sur /v1/organizations/federation_rules/{rule_id}. Pour gérer les workspaces dans lesquels une règle peut générer des jetons, utilisez GET et POST sur /v1/organizations/federation_rules/{rule_id}/workspaces, et DELETE sur /v1/organizations/federation_rules/{rule_id}/workspaces/{workspace_id}.



Permissions et contraintes

Une règle avec oauth_scope: org:admin doit cibler un compte de service dont le organization_role est admin. Les noms de ressources doivent correspondre à ^[a-z0-9-]+$, comporter de 1 à 255 caractères et être uniques au sein d'une organisation pour chaque type de ressource ; pour les contraintes complètes au niveau des champs, voir Règles de validation.



Pagination et archivage

Les points de terminaison de liste des comptes de service, des émetteurs de fédération et des règles de fédération acceptent limit (de 1 à 100, 20 par défaut) et un curseur page tiré de la réponse précédente. Passez la valeur next_page de la réponse comme paramètre de requête page lors de la requête suivante. La liste de la sous-ressource rule-workspaces renvoie l'ensemble complet sans pagination. Les ressources archivées sont masquées des listes par défaut ; passez include_archived=true pour les inclure.

L'archivage est une suppression logique et est idempotent : archiver une ressource déjà archivée réussit. L'archivage d'un émetteur ou d'un compte de service renvoie 400 tant qu'une règle de fédération active y fait encore référence ; archivez d'abord la règle.



Voir aussi

• Workload Identity Federation : concepts et procédure de configuration dans la Console
• Référence WIF : variables d'environnement, règles de validation, scopes OAuth et codes d'erreur
• Admin API : le reste de la surface de gestion de l'organisation
• Référence de l'Admin API : schémas de requête et de réponse générés pour chaque point de terminaison de l'Admin API