Unlocking the power of automation in VMware Cloud Foundation (VCF) 9.1 requires a solid understanding of how to manage programmatic access. By transitioning from manual administration to an API-first approach, you can ensure consistency, scalability, and security across your entire VCF fleet.
This blog post helps you understand identity types in the context of VCF SSO and provides a step-by-step guide to obtaining API tokens for the VCF 9.1 API access.
1. Understanding Identity Types: SSO User (for humans) vs API Client (for systems)
VCF 9.1 categorizes programmatic access into two distinct identity types.
| Identity Type | User Category | Use Case | Lifecycle Implication |
| SSO User | Humans / Admins | Manually triggered or on-demand API tasks. | Tokens fail if the individual’s personal account is disabled or deleted. |
| API Client | Systems / Services | Automation, monitoring, or CI/CD integrations. | Tokens remain active even if the admin who created them leaves, ensuring integration reliability. |
2. Obtaining an API Token as an SSO User
For administrative tasks that require manual API calls, human users can generate personal tokens through the VCF interface.
- Process: SSO users log into the VCF Components UI (such as VCF Automation, vCenter, or NSX) or VCF Operations to generate an API token.
- Token Exchange: This initial API token is exchanged with the Identity Broker for a short-lived bearer access token used for fleet-wide operations.
- Crucial Limitation: API tokens only inherit permissions assigned at the VCF Fleet level. For example, if you are a “vCenter Admin” but only a “VCF Viewer” at the fleet level, your API token will only grant you Viewer permissions.
3. Obtaining an API Token for System Access (API Clients)
To support robust, “headless” automation, you should manage API clients as first-class operational objects.
Step 1: Create the API Client
In VCF Operations, an administrator creates an API Client. It is recommended to create separate clients for distinct functions, such as one for “Backup” and another for “Monitoring,” to follow the Principle of Least Privilege.
Step 2: Generate the API Token
Once the client is defined, you can generate one or multiple API tokens associated with that specific client.
The generated token can then be used by your external automation system. This token is sent to the Identity Broker, which validates the client and issues the bearer access token required for API calls.
An example of a VIDB API token
vidb_ZTkwMmRkMzItMDIwOC00Y2E0LTkzYmYtYzg2ZmQ3YzEyY2YyI1NoUEhzMHozWXF4aHVqU0ZiZmhJcTYyblh4ZEtqM2pCTDZ3WjFZaGNwVTZ1cFZLakRGNjkxTVFEQWQ0T2dlSWsjMTc3NDI0MzU0NQ
4. How to exchange API Token for Bearer Access Token
Once you have your API token (either from an SSO User or an API Client), you must exchange it with the Identity Broker to retrieve your functional bearer token.
Use the following POST request to perform the exchange:
curl --request POST \ --url https://{{idb-fqdn}}//acs/t/CUSTOMER/token \ --header 'content-type: application/x-www-form-urlencoded' \ --data grant_type=urn:custom:vcf:params:oauth:grant-type:api-token \ --data api_token=vidb_xxxxxxxxxxxxxxxxxx
Understanding these foundational identity concepts and token exchange mechanics is the first step toward secure VCF automation. In our next post, we will dive into advanced scenarios, including IdP-Validated Access for high-security environments!
davidwzhang.com 