prerequisites

Prerequisites

The Admin SDK examples authenticate as a management application via the OAuth 2.0 client_credentials grant and drive the Admin API (/api/v3/admin/**). Before running any example you must:

1. Provide connection settings. The SDK reads its endpoint from the adminsdk.* keys in a cli.properties file (loaded from the working directory, from the file named by the cli.config system property, or from the classpath):

   • adminsdk.scheme — https (or http for a plain local endpoint).
   • adminsdk.host — the Admin API host (edge or direct).
   • adminsdk.port — the Admin API port.

2. Provide the management client credentials. The client id and the (optional) bound tenant come from the environment or the same cli.properties; the secret is read into a zeroizable buffer and closed immediately after authentication:

   • ADMIN_CLIENT_ID env var (or the adminsdk.clientId property).
   • ADMIN_CLIENT_SECRET env var (or the admin.client.secret system property, or the interactive console prompt).
   • ADMIN_TENANT_ID env var (or the adminsdk.tenantId property) — the tenant the SDK is scoped to. It is optional: with no tenant the SDK holds a platform-scope session and the tenant-scoped scenarios skip gracefully.

3. Point at a STANDARD tenant for the read scenarios. The tenant-scoped read examples (inventory of keys, actors, users, policies, audit) need a STANDARD (not SIMPLE) tenant that hosts those resources. A call that is not permitted or not applicable is reported and skipped on its transport status (403 / 422) — the examples never infer intent from a failure.

The mutating scenarios (Admin Scenarios 9–14 — runtime identity provisioning, key create, exchange grants, internal crypto use cases, tenant policies, organisation model) create and then clean up resources, so run them against a disposable sandbox tenant, never production data. Every created resource is registered for best-effort, idempotent cleanup.