VCF 9.1 Identity Broker and SSO Federation A Day 0/1/2 Field Guide

Identity is the architectural layer that touches every other decision in VCF: who can deploy a workload domain, who can self-service a Kubernetes cluster, who sees which tenant’s cost data, who can patch which cluster. Get identity wrong at Day 0 and it constrains everything downstream. Get it right and most of the operational governance conversation becomes straightforward.

VCF 9.1 introduces VCF Identity Broker as a consolidated identity layer within VCF Management Services. It supports federation to Azure AD/Entra, Okta, Ping, ADFS, and any OIDC-compliant identity provider, and it operates as either a single appliance or a three-node cluster. This piece walks through the design, deployment, and operational considerations across Day 0/1/2.

Day 0 Designing the Identity Architecture

The Day 0 identity design questions decide far more than just “who can log in.” They shape multi-tenancy boundaries, the operational governance model, and the audit posture.

• Primary IdP selection Azure AD/Entra is the most common enterprise choice; Okta is common for federated workforce identity; ADFS persists in legacy environments; Ping in regulated sectors. Pick one as the system of record; treat others as supplementary.

• Group governance model IdP groups map to VCF roles. Decide group naming convention, owner, and lifecycle management before deployment. AD group sprawl is the most common failure mode at Day 365.

• Multi-instance federation scope a single VCF Identity Broker can federate across multiple VCF instances. Decide whether to centralise (single broker for fleet) or federate-per-instance (regulatory isolation).

• MFA enforcement MFA at the IdP, not at VCF. VCF Identity Broker trusts the IdP’s authentication assertions; MFA policy lives upstream.

• Service account strategy humans federate; service accounts use API tokens with scoped roles. Don’t federate service accounts; treat them as a separate identity class.

A note on MGL-pattern decisions: customers with strong AD group governance often resist VCF SSO in its current form because of the operational overhead of synchronising AD groups to VCF roles. The Day 0 decision in these cases is whether to adopt VCF SSO with phased role onboarding, or to defer to native vCenter/NSX SSO with deeper IdP integration. The trade-off is governance simplicity (VCF SSO) versus operational autonomy (per-product SSO). Make this decision explicitly in the HLD; don’t let it default by accident.

Identity Broker placement matters. Three-node cluster is the production default for HA and rolling-upgrade compatibility. Single-node is acceptable for non-production but creates a single point of failure for the entire control plane authentication path.

Day 1 Deploying Identity Broker

VCF Identity Broker deploys as part of VCF Management Services and configures via VCF Operations. The Day 1 deployment sequence is straightforward but unforgiving of misconfiguration.

• Deploy three-node VCF Identity Broker cluster within VCF Management Services. DNS records must be lower-case; certificates must be valid and trusted by the IdP.

• Configure primary IdP federation SAML or OIDC depending on IdP. Test with a single seed user before mass enrolment.

• Map IdP groups to VCF roles use named groups, not embedded SIDs. Document the mapping in the HLD; treat it as configuration artefact.

• Enable VCF SSO across vCenter and NSX vCenter Server Linking is required for multi-vCenter SSO. Workload Domains using VCF SSO need this configuration in place.

• Configure service account API tokens separately scoped roles, rotation policy, audit logging.

• Validate authentication paths admin user, tenant user, service account. Confirm each role lands in the expected scope before opening to broader users.

A common Day 1 misstep: treating the Identity Broker deployment as “set it up and forget it.” Identity is a living configuration. The architect should hand over a documented group-to-role mapping, a recovery procedure if the IdP becomes unreachable (VCF Identity Broker has a local fallback admin), and a rotation schedule for service account tokens. Without these, the operations team inherits a black box.

Certificate management at Day 1 is also where customers using enterprise PKI (Venafi TPP, Microsoft ADCS, HashiCorp Vault) need to integrate. VCF Identity Broker certificates should be issued by the enterprise PKI; self-signed certificates are acceptable only for non-production. Renewal automation should be configured Day 1, not retrofitted later.

Day 2 Operating Federated Identity

Day 2 identity operations are about discipline rather than complexity. The work is consistent and steady: access reviews, lifecycle, rotation, audit.

Access Reviews and Lifecycle

IdP-driven joiner-mover-leaver flows propagate to VCF automatically via group membership changes. The Day 2 operational task is access reviews typically quarterly confirming that group memberships still match the principle of least privilege. The architect should provide an access review template based on the role mapping documented at Day 1.

MFA and Conditional Access

MFA policy lives in the IdP, not in VCF. For regulated customers, conditional access policies (location, device posture, risk-based) apply transparently to VCF authentication. The VCF architect should validate with the security team that VCF authentication paths are covered by enterprise conditional access policy.

Service Account Hygiene

API tokens for service accounts require rotation. VCF Operations supports scheduled rotation and automated re-key for service accounts integrated with the platform. For external integrations (CI/CD, monitoring, ITSM), the rotation cadence should match the enterprise standard typically 90 days for high-privilege tokens, 180 for read-only.

Audit and Compliance Evidence

VCF Operations audit logs capture authentication events, role assignments, and privileged operations. Stream these to the enterprise SIEM via Syslog. Audit evidence for SOC 2, ISO 27001, PCI DSS, APRA CPS 234 should be drawable from the audit log without bespoke instrumentation.

A note on multi-tenant federation: for MSPs operating VCF as a service, per-tenant IdP federation is the architectural pattern each tenant federates to its own IdP, with the MSP’s tenants isolated by VPC and Identity Broker scope. The operational pattern is: MSP runs the platform; tenants run their identity. Get the boundary right at Day 0, and Day 2 operations are sustainable. Get it wrong, and you’re managing 50 customer IdPs from one console.

Architect’s Takeaway

Identity in VCF 9.1 is operationally simpler than in 5.2.x but architecturally more consequential. The decisions you lock in at Day 0 primary IdP, federation scope, group governance, MFA placement shape what Day 2 operations look like. Three-node Identity Broker for production. Enterprise PKI from Day 1. Group-to-role mapping documented as an architectural artefact. Quarterly access reviews built into the operational runbook. The customers who treat identity as an architectural concern from the HLD onward run smoother Day 2 operations than those who treat it as a Day 1 task to be completed.

Sources

• Broadcom Announcing VCF 9.1: Modern Private Cloud Built for Efficiency and Resilience

• Broadcom Strengthen Zero Trust Platform Security and Resilience with VCF 9.1

• Broadcom VCF 9.1: The Secure, Cost-Effective Private Cloud Platform for Production AI

• Broadcom Modernizing Infrastructure: VMware Cloud Foundation 5.2.x to 9.1 Upgrade Guide

Broadcom Scale, Simplify, and Secure Your Private Cloud Operations with VCF 9.1