Dr. Pranay Jha

A user logs in. The OIDC redirect works, the consent screen looks right, they land in the organization portal, and then they can see nothing. No catalog, no deployments, no projects. The account is authenticated and completely unauthorized. Nine times out of ten the IdP is fine and the problem is one missing claim: the group names never made it into the token, so VCF Automation cannot match the user to any role. That single gap is the reason identity work on this platform eats an afternoon instead of ten minutes, and it is where this part starts.

Two identity planes, not one

VCF Automation (the product formerly named VMware Aria Automation, and before that vRealize Automation) inherited a multi-tenant identity model from its vCloud Director lineage, and VCF 9 layered the new fleet-wide single sign-on on top. The result is two distinct planes, and treating them as one is where designs go wrong.

The provider plane is how provider administrators reach the provider portal and every other VCF management component. In VCF 9 that path runs through VCF SSO and the VCF Identity Broker. The tenant plane is how members of an individual organization reach their organization portal, and each organization can point at its own external identity provider. A service provider running thirty customer tenants can give every tenant a separate IdP. An enterprise with one corporate directory can reuse it across all of them. The platform supports both, and the choice is a design decision, not a default.

VCF SSO and the Identity Broker for the provider

The VCF Identity Broker is the piece VCF 9 added that older vRA admins will not recognize. It is a component of VCF Operations, deployed embedded or external, and it brokers your real IdP to every VCF management component. Configure it once and a provider administrator signs in to vCenter, NSX Manager, VCF Operations and the VCF Automation provider portal with the same identity and the same session story. VCF 9.0 widened the list of supported brokered IdPs to include Ping Identity and a generic SAML 2.0 provider, alongside Okta, Microsoft Entra ID, Microsoft Active Directory, ADFS and OpenLDAP.

The wiring, end to end

You configure VCF SSO inside VCF Operations under Fleet Management, in the Identity and Access area. For VCF Automation specifically there is a useful pattern: you create an OIDC client for the provider plane, then a separate OIDC client for each organization you want to bring under the same broker. The broker hands out an issuer URL shaped like https://<host>/acs/t/<TENANT>, and the well-known discovery document lives at that URL with /.well-known/openid-configuration appended. That issuer URL is what the organization portal consumes.

The Service Broker and Assembler services themselves did not change their underlying access model in this transition. What changed is the front door and the shell. In VCF 9 the Assembler, Service Broker and Orchestrator user interfaces are merged into one VCF Automation interface, so the identity you present at the door determines which of those surfaces you can even see.

Per-organization identity for tenants

Each organization can attach to its own external IdP, configured in the organization portal under Administer, then Connections, then Identity Providers. OIDC, LDAP and SAML are all supported at the organization level. In a service-provider model that isolation is the whole point: customer A authenticates against customer A directory and never touches yours. For an enterprise running internal tenants, you usually reuse one directory but still create a distinct OIDC client per organization so you can revoke or rotate one tenant without disturbing the others.

The claim mapping that decides everything

Authentication proves who you are. Authorization needs the token to carry attributes VCF Automation can match against role assignments, and this is where most setups stall. Two mappings matter. Set the subject claim to acct so the user identifier is stable. Then map groups, because group-based assignment is how you avoid naming every user by hand. Group membership does not arrive on its own. You have to request the group scope and add a claim mapping that pulls the IdP group attribute into the group_names claim. Miss it and individual users log in fine while every group you imported sits inert.

Custom roles, rights bundles and global roles

Authentication gets a user in the door. RBAC decides what they can do once inside, and VCF Automation expresses it through three constructs that map cleanly onto the provider-and-tenant split. A right is a single fine-grained permission. A rights bundle is a set of rights the provider publishes to organizations, which gates what an organization is even allowed to grant. A global role is a role template the provider defines once and publishes to many tenants, so the same role means the same thing everywhere. Inside a tenant, organization administrators can then create org-local roles or use the published ones, and project membership scopes those rights down to a project.

The discipline that holds up is simple: the provider publishes, the tenant consumes. Define rights bundles and global roles centrally, push them out, and resist the urge to hand-craft a bespoke role inside each tenant. The moment role definitions drift tenant by tenant, your audit story falls apart and a permissions question takes a day to answer instead of a minute. VCF 9.1 extended what providers can delegate, adding the ability to hand organization administrators rights over vDefend distributed and gateway firewall and Avi load balancing, so the rights-bundle surface is wider than it was at 9.0.

One operational note that trips people up: rights bundles may not appear in the provider Access Control area until the advanced rights mode feature flag is enabled. If you created a bundle through the API or Terraform and cannot find it in the UI, that flag is usually why. This connects to the broader access model covered in Projects in VCF Automation and the token mechanics in the VCF Automation API and token authentication.

Automating it with the vmware/vcfa Terraform provider

Configuring an organization OIDC IdP by hand is a 15-minute clickfest you will repeat per tenant and per rebuild. The vmware/vcfa provider, currently v1.0.0, turns it into a few lines that apply in seconds. It is the same provider used for organizations, regions, projects and IaaS resources, and it is distinct from vmware/vcf, which manages SDDC Manager and fleet infrastructure. The provider exposes an vcfa_org_oidc resource for OIDC and vcfa_provider_ldap for LDAP. SAML is supported in the product UI but is not yet in the provider, so a SAML org is still a manual step.

data "vcfa_org" "tenant" {
  name = "acme-prod"
}

resource "vcfa_org_oidc" "acme" {
  org_id             = data.vcfa_org.tenant.id
  enabled            = true
  client_id          = var.oidc_client_id
  client_secret      = var.oidc_client_secret
  wellknown_endpoint = var.oidc_client_well_known_url
  prefer_id_token    = true
  ui_button_label    = "Login with corporate SSO"

  scopes = ["openid", "profile", "email", "group"]

  claims_mapping {
    subject   = "acct"
    email     = "email"
    full_name = "name"
    groups    = "group_names"
  }
}

Expected result: terraform apply creates the OIDC provider in that organization under Administer, Connections, Identity Providers, with the group scope and claim already correct, so you do not rediscover the group gotcha by hand on every tenant. The failure mode to watch: if you omit the group scope here, the apply still succeeds and you ship the same broken authorization, just faster.

Bring-your-own signing keys

The OIDC config can auto-generate its JSON Web Key Set, or you can supply your own. If your security team requires managed keys, generate an RSA pair and the matching key ID, which is a base64url-encoded SHA-256 of the public key, before the apply:

openssl genpkey -algorithm RSA -out rsa-key1.pem -pkeyopt rsa_keygen_bits:2048
openssl pkey -in rsa-key1.pem -pubout -out rsa-key1.pub.pem

openssl pkey -in rsa-key1.pub.pem -pubin -outform DER | 
  openssl dgst -binary -sha256 | 
  openssl base64 | tr '+/' '-_' | tr -d '=' > kid1.txt

If you are coming at this from the infrastructure side rather than the product side, the companion approach for SDDC Manager and fleet tooling lives in VCF 9 API authentication and RBAC from the Automating VCF Series, which is a separate track from this product series.

My take

Run the provider plane through VCF SSO and the Identity Broker, give tenants their own IdP only when isolation actually demands it, and drive your roles from provider-published rights bundles and global roles rather than per-tenant hand-editing. That combination keeps one login across VCF, keeps tenant boundaries honest, and keeps an audit answerable. The exception is the hard service-provider case where a customer must own their directory end to end, where a per-org IdP earns its keep despite the extra clients to manage. Before any of it goes live, validate the group claim, because that is the single point that turns a clean login into a useless one. What I would not do is wire the provider org straight to the corporate IdP to save an hour, or let org-local roles multiply until nobody can say who can do what.

Building a new instance this week? Configure VCF SSO first, then template one organization OIDC config in Terraform and reuse it for every tenant.

← Previous: Consuming All Apps the Kubernetes-Native Way (Part 37)

Up: VCF Automation Guide (series pillar)

Related: Tenant Organizations (Part 7) · Multi-Tenancy at Scale (Part 24)

References

Broadcom TechDocs: VCF Automation Role-Based Access Control

William Lam: VCFA organization identity providers and the group claim mapping

William Lam: Configuring an organization OIDC IdP with the vmware/vcfa Terraform provider

GitHub: vmware/terraform-provider-vcfa (v1.0.0)

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts