Gérer WIF avec l'Admin API

L'Admin API vous permet de créer et de gérer par programmation les ressources de Workload Identity Federation (fédération d'identité de charge de travail) : les « service accounts » (comptes de service), les « federation issuers » (émetteurs de fédération) et les « federation rules » (règles de fédération). Utilisez-la pour conserver votre configuration de fédération sous forme d'« infrastructure as code » (infrastructure en tant que code), la provisionner depuis la CI et la reproduire d'une organisation à l'autre 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 « bearer token » (jeton porteur) OAuth qui porte le « scope » (portée) org:admin. Cette portée n'est accordée qu'aux membres de l'organisation ayant le rôle admin, owner ou primary owner, et elle donne accès à l'ensemble de l'organisation : toute liaison à un espace de travail 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 de cette page.

Interactif (votre terminal)

Connectez-vous avec la CLI ant sous un profil dédié, en demandant la portée org:admin (voir Accès administrateur), puis exportez le jeton porteur. La connexion avec --profile admin stocke l'identifiant org:admin sous son propre nom de profil et en fait également le profil actif de la CLI, et la variable exportée s'applique à chaque appel de SDK et de CLI dans ce shell ; utilisez donc un shell que vous réservez à l'administration, supprimez la variable lorsque vous avez terminé, et rebasculez la CLI avec ant profile activate default :

ant auth login --profile admin --scope "org:admin"
export ANTHROPIC_AUTH_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'export (elle actualise le jeton automatiquement).

Les SDK et la CLI ant lisent ANTHROPIC_AUTH_TOKEN automatiquement ; laissez ANTHROPIC_API_KEY non définie dans le même shell, car ces points de terminaison rejettent les clés API et certains clients préfèrent la clé lorsque les deux sont définies.

Charge de travail (CI et automatisation)

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

Amorcer une charge de travail 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 à une seule charge de travail de confiance la portée org:admin, et laissez cette charge de travail gérer les émetteurs de fédération et chaque règle de fédération à portée d'espace de travail via cette API.

1. 1

   Créer la règle org:admin dans la Console

   Dans la Claude Console, accédez à Settings → Workload identity et sélectionnez Connect workload pour créer une règle de fédération pour votre charge de travail d'automatisation, par exemple un workflow GitHub Actions dans votre dépôt d'infrastructure. Sous Advanced rule options, définissez la portée OAuth de la règle sur org:admin : l'assistant crée alors le nouveau compte de service avec le rôle d'organisation Admin (ou vous demande de choisir un compte de service admin existant comme cible).

2. 2

   Échanger le jeton d'identité de la charge de travail

   Une charge de travail qui utilise l'un des SDK ou la CLI ant n'effectue pas l'échange elle-même. Pointez le client vers la règle avec les variables d'environnement de fédération et construisez-le sans arguments, exactement comme pour l'inférence dans Construire le client SDK ; le client échange le jeton d'identité lors de la première requête et, avant l'expiration du jeton d'accès obtenu, relit le jeton d'identité et l'échange à nouveau :

   export ANTHROPIC_FEDERATION_RULE_ID=fdrl_...        # the org:admin rule from step 1
   export ANTHROPIC_ORGANIZATION_ID=00000000-0000-0000-0000-000000000000
   export ANTHROPIC_SERVICE_ACCOUNT_ID=svac_...       # the rule's target service account
   export ANTHROPIC_IDENTITY_TOKEN_FILE=/path/to/jwt  # or ANTHROPIC_IDENTITY_TOKEN
   # ANTHROPIC_WORKSPACE_ID n'est requis que si la règle est activée pour tous les
   # espaces de travail ou plusieurs ; les points de terminaison org:admin ignorent la liaison.
   unset ANTHROPIC_API_KEY ANTHROPIC_AUTH_TOKEN       # both take precedence over federation

   

   La CLI ant lit les mêmes variables, ou accepte les options --federation-rule, --organization-id, --service-account-id et --identity-token-file. Pour une charge de travail qui exécute plus d'une commande ant, utilisez un profil de fédération plutôt que des options ou des variables d'environnement : avec des options ou des variables, la CLI échange à nouveau le jeton d'identité dans chaque processus, et les jetons d'identité qui portent une revendication jti (c'est le cas des jetons GitHub Actions) ne sont acceptés qu'une seule fois, de sorte qu'une deuxième commande serait rejetée ; un profil est également le seul moyen de fournir à la CLI un workspace_id pour l'échange lorsque la règle est activée pour tous les espaces de travail ou pour plusieurs, car contrairement aux SDK, la CLI ne transmet pas ANTHROPIC_WORKSPACE_ID ni --workspace-id dans l'échange. Chaque SDK accepte également les mêmes paramètres sous forme d'arguments explicites du constructeur, présentés par langage dans Construire le client SDK. Voir Variables d'environnement et Priorité des identifiants pour la liste complète et l'ordre de priorité.

   Une charge de travail qui appelle l'API avec curl échange elle-même le JWT contre un jeton porteur org:admin de courte durée, en utilisant le même échange de jeton que toute autre charge de travail fédérée, et l'envoie dans l'en-tête authorization: Bearer.

3. 3

   Gérer les émetteurs et les règles à portée d'espace de travail via l'API

   Une fois le client configuré (ou, pour curl, le jeton émis placé dans ANTHROPIC_AUTH_TOKEN), la charge de travail crée et gère votre configuration de fédération à l'aide des points de terminaison de cette page.

Pour connaître les opérations qu'un jeton émis par une charge de travail 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 comptes de service nécessite l'en-tête de version de l'API et le jeton porteur :

Dans les SDK, ces points de terminaison sont client.beta.organization.service_accounts, client.beta.organization.federation.issuers et client.beta.organization.federation.rules (ant beta:organization:service-accounts, federation:issuers et federation:rules dans la CLI). Les exemples SDK et CLI construisent le client par défaut, qui envoie le jeton porteur depuis ANTHROPIC_AUTH_TOKEN ou, dans une charge de travail automatisée, effectue lui-même l'échange de fédération comme décrit dans Amorcer une charge de travail pour gérer WIF. Les méthodes de liste des SDK récupèrent les pages suivantes à la demande, de sorte que limit définit la taille de page ; les exemples PHP et Ruby lisent une seule page.

client = anthropic.Anthropic()

service_accounts = client.beta.organization.service_accounts.list()

for service_account in service_accounts:
    print(f"{service_account.id}: {service_account.name}")

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 en tant que laquelle agit un jeton fédéré. Définissez organization_role sur developer.

Créer un compte de service :

client = anthropic.Anthropic()

service_account = client.beta.organization.service_accounts.create(
    name="inference-worker", organization_role="developer"
)

print(f"id: {service_account.id}")
print(f"name: {service_account.name}")

Lister les comptes de service :

client = anthropic.Anthropic()

service_accounts = client.beta.organization.service_accounts.list(limit=20)

for service_account in service_accounts:
    print(f"{service_account.id}: {service_account.name}")

Archiver un compte de service :

client = anthropic.Anthropic()

service_account = client.beta.organization.service_accounts.archive(
    "svac_01ABCDEFabcdef0123456789XY"
)

print(f"id: {service_account.id}")
print(f"archived_at: {service_account.archived_at}")

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 individuel, utilisez GET et POST sur /v1/organizations/service_accounts/{service_account_id}. Un compte de service doit être membre d'un espace de travail avant que des jetons fédérés puissent y agir. Chaque compte de service dispose d'une appartenance implicite à l'espace de travail par défaut de votre organisation ; ajoutez des appartenances explicites pour d'autres espaces de travail avec GET, POST et DELETE sur /v1/organizations/service_accounts/{service_account_id}/workspaces, où DELETE cible .../workspaces/{workspace_id}.

Pour le détail complet des paramètres et les schémas de réponse, consultez la référence API des comptes de service.

É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. Cet exemple enregistre GitHub Actions avec la découverte JWKS :

client = anthropic.Anthropic()

issuer = client.beta.organization.federation.issuers.create(
    name="github-actions",
    issuer_url="https://token.actions.githubusercontent.com",
    jwks={"type": "discovery"},
)

print(f"id: {issuer.id}")
print(f"name: {issuer.name}")
print(f"issuer_url: {issuer.issuer_url}")

Lister les émetteurs :

client = anthropic.Anthropic()

issuers = client.beta.organization.federation.issuers.list(limit=20)

for issuer in issuers:
    print(f"{issuer.id}: {issuer.name}")

Archiver un émetteur :

client = anthropic.Anthropic()

issuer = client.beta.organization.federation.issuers.archive(
    "fdis_01ABCDEFabcdef0123456789XY"
)

print(f"id: {issuer.id}")
print(f"archived_at: {issuer.archived_at}")

Pour lire ou mettre à jour un émetteur individuel, 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 l'oauth_scope est autre que workspace:developer ou workspace:inference ; voir Permissions et contraintes.

Pour le détail complet des paramètres et les schémas de réponse, consultez la référence API des émetteurs de fédération.

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 les conditions de correspondance de la règle peuvent émettre 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 cet espace de travail dès la création ; ajoutez d'autres espaces de travail 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. Cet exemple permet aux déploiements GitHub Actions depuis la branche main d'agir en tant que compte de service :

client = anthropic.Anthropic()

rule = client.beta.organization.federation.rules.create(
    name="gha-deploy",
    issuer_id="fdis_01ABCDEFabcdef0123456789XY",
    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_01ABCDEFabcdef0123456789XY",
    },
    workspace_id="wrkspc_01JwQvzr7rXLA5AGx3HKfFUJ",
    oauth_scope="workspace:developer",
    token_lifetime_seconds=600,
)

print(f"id: {rule.id}")
print(f"name: {rule.name}")

Lister les règles, éventuellement filtrées par émetteur :

client = anthropic.Anthropic()

rules = client.beta.organization.federation.rules.list(
    issuer_id="fdis_01ABCDEFabcdef0123456789XY"
)

for rule in rules:
    print(f"{rule.id}: {rule.name}")

Archiver une règle :

client = anthropic.Anthropic()

rule = client.beta.organization.federation.rules.archive(
    "fdrl_01ABCDEFabcdef0123456789XY"
)

print(f"id: {rule.id}")
print(f"archived_at: {rule.archived_at}")

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

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

Pour lire ou mettre à jour une règle individuelle, utilisez GET et POST sur /v1/organizations/federation_rules/{rule_id}. Pour gérer les espaces de travail dans lesquels une règle peut émettre 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}.

Pour le détail complet des paramètres et les schémas de réponse, consultez la référence API des règles de fédération.

Permissions et contraintes

Une règle avec oauth_scope: org:admin doit cibler un compte de service dont l'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 l'ensemble des contraintes 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 issu de la réponse précédente. Transmettez 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 des espaces de travail d'une règle renvoie l'ensemble complet sans pagination. Les ressources archivées sont masquées des listes par défaut ; transmettez 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 guide de configuration dans la Console
• Référence WIF : variables d'environnement, règles de validation, portées OAuth et codes d'erreur
• Admin API : le reste de la surface de gestion de l'organisation
• Référence Admin API : schémas de requête et de réponse générés pour chaque point de terminaison de l'Admin API