6.2 Identity Federation, VCF Identity Broker, & RBAC

6.2 Identity Federation, VCF Identity Broker, & RBAC

Exam Focus: Managing authentication, authorization, and administrative governance across a multi-component cloud platform requires a unified identity architecture. For the VCP-VCF (2V0-17.25) exam, candidates must understand how VMware Cloud Foundation 9.0 integrates enterprise identity sources through the native VCF Identity Broker, how OpenID Connect (OIDC) and SAML 2.0 federation propagate Single Sign-On (SSO) tokens across SDDC Manager, vCenter, and NSX, and how Role-Based Access Control (RBAC) maps enterprise directory groups to predefined system roles while adhering to the principle of least privilege.

[!IMPORTANT] Where this lives in VCF 9.0. Broadcom moved the fleet-wide management surface in VMware Cloud Foundation 9.0. VCF Operations provides the fleet management capabilities — fleet extension, lifecycle, certificate, and password management. SDDC Manager still exists as a per-instance component and can still perform several of these tasks, but the SDDC Manager UI is deprecated and is slated for removal in a future major release, its lifecycle management APIs have moved to VCF Operations, and its identity-configuration APIs are deprecated in favour of VCF Operations. When an exam item asks where a fleet-wide task is performed in 9.0, VCF Operations is the current answer; treat SDDC Manager as the legacy surface that remains for compatibility.

---

Enterprise Identity Architecture in VCF 9.0

In early virtualization deployments, identity management was fragmented: administrators maintained independent local accounts or configured point-to-point Active Directory identity sources inside every individual vCenter Server and NSX Manager appliance. This siloed model introduced substantial operational risk, including uncoordinated access revocations, credential sprawl, lack of centralized auditability, and inability to enforce corporate Multi-Factor Authentication (MFA) or conditional access policies.

VMware Cloud Foundation 9.0 standardizes on a centralized enterprise identity federation model. Rather than each component managing its own authentication mechanics, VCF establishes a unified security broker layer that bridges corporate Identity Providers (IdPs) with the software-defined data center stack. In VCF 9.0 this role belongs to the native VCF Identity Broker, which succeeds VMware Workspace ONE Access (earlier VMware Identity Manager / vIDM) in the VCF identity path. The broker (integrating with vCenter Identity Provider Federation) to act as the authoritative identity federation gateway.

Under this decoupled model:

• Enterprise credentials never touch the local authentication databases of SDDC Manager, vCenter, or NSX.
• Users authenticate exclusively against the corporate IdP, which evaluates enterprise security policies (MFA, IP geofencing, device compliance).
• Authenticated identities and their corresponding directory group claims are passed to VCF components via cryptographically signed tokens, establishing a seamless Single Sign-On (SSO) experience across the entire private cloud.

---

Supported Federation Protocols & Identity Sources

VCF 9.0 accommodates diverse enterprise identity backends through industry-standard open federation protocols.

1. OpenID Connect (OIDC) 1.0 & OAuth 2.0

OpenID Connect is an identity layer built on top of the OAuth 2.0 authorization framework. In VCF 9.0, OIDC represents the modern standard for federating with enterprise cloud and modern on-premises identity providers, such as Microsoft Entra ID (formerly Azure Active Directory), Okta, PingFederate, and Google Cloud Identity.

• Protocol Mechanics: SDDC Manager and vCenter register as confidential OAuth client applications with the external IdP using a Client ID and Client Secret (or public key certificate). The federation configuration references the IdP's standard OpenID discovery endpoint (/.well-known/openid-configuration).
• Token Exchange: When a user logs in, the browser is redirected to the IdP. Upon successful authentication, the IdP returns an ID Token (an RFC 7519-compliant JSON Web Token / JWT) containing identity assertions and an Access Token conveying authorization scopes.

2. SAML 2.0 (Security Assertion Markup Language)

SAML 2.0 remains widely used in established enterprise architectures. In a SAML federation:

• Roles: The external IdP operates as the SAML Identity Provider, while the VCF Identity Broker acts as the SAML Service Provider (SP).
• Metadata Exchange: Mutual trust is established by exchanging XML metadata documents containing Entity IDs, Assertion Consumer Service (ACS) URLs, Single Logout (SLO) endpoints, and X.509 public signing certificates.
• Assertions: The IdP issues digitally signed XML assertions containing the user's Principal Name (UPN) and security group memberships.

3. Active Directory over LDAPS (TCP 636)

For traditional on-premises Microsoft Active Directory environments, VCF supports direct directory binding using Active Directory over Secure LDAP (LDAPS).

[!IMPORTANT] The LDAPS Security Requirement: Unencrypted LDAP (TCP port 389) transmits user credentials and directory search queries in cleartext, violating enterprise security baselines. VCF 9.0 enforces encrypted LDAPS over TCP port 636 (or port 3269 for Global Catalog queries). Integrating LDAPS requires administrators to upload the root and intermediate Certificate Authority (CA) certificates that signed the Active Directory domain controllers' certificates into the VCF truststore. Failure to establish root trust results in immediate connection termination during directory binding.

---

SSO Token Propagation Across SDDC Manager, vCenter, & NSX

In a multi-component VCF private cloud, administrators frequently navigate between SDDC Manager (for domain and lifecycle tasks), vCenter Server (for virtual machine and datastore operations), and NSX Manager (for virtual network routing and distributed firewall policies). Forcing re-authentication at each management boundary disrupts operational workflows and degrades administrator productivity.

To solve this, VCF 9.0 implements Single Sign-On (SSO) token propagation across the entire stack:

Identity Federation & Token Propagation Flow:

 ┌──────────────┐         ┌────────────────────────┐         ┌─────────────────────────┐
 │  Admin User  │ ──────> │  VCF Identity Broker   │ ──────> │ Enterprise IdP (EntraID)│
 │   (Browser)  │         │   (VCF 9.0 identity)   │         │ - MFA / Conditional Acc │
 └──────┬───────┘         └────────────────────────┘         └────────────┬────────────┘
        │                                                                 │
        │ 1. Redirect to IdP                                              │ 2. Authenticates &
        │ <───────────────────────────────────────────────────────────────┘    issues signed JWT
        │
        │ 3. Presents JWT Bearer Token
        ├───────────────────────────────────────────────────────┐
        ▼                                                       ▼
 ┌────────────────────────┐                           ┌─────────────────────────┐
 │      SDDC Manager      │                           │  vCenter Server / NSX   │
 │ - Validates via JWKS   │ ── Token Context Prop ──> │ - Inherits User Identity│
 │ - Maps SDDC RBAC Role  │                           │ - Evaluates Local RBAC  │
 └────────────────────────┘                           └─────────────────────────┘

The Token Handshake Sequence

1. Authentication Request: The administrator navigates to the SDDC Manager URL. SDDC Manager detects an unauthenticated session and redirects the browser to the VCF Identity Broker login URL.
2. IdP Challenge: The broker redirects to the configured enterprise IdP (e.g., Microsoft Entra ID). The user inputs their corporate credentials and completes the mandatory Multi-Factor Authentication (MFA) challenge.
3. Token Issuance: The IdP generates a signed JSON Web Token (JWT) containing cryptographic claims: user identifier (sub), user principal name (upn), email, token expiry (exp), and corporate directory group memberships (groups).
4. Cryptographic Validation via JWKS: The browser delivers the JWT to SDDC Manager. SDDC Manager retrieves the IdP's public signing keys from its published JSON Web Key Set (JWKS) endpoint and verifies the cryptographic signature, confirming the token's authenticity without transmitting the user's password.
5. Cross-Component Propagation: When the administrator launches vCenter Server or NSX Manager from within the SDDC Manager console, the user's validated identity context and authorization claims are propagated via federated HTTP authorization headers. The target vCenter or NSX appliance verifies the shared token trust and admits the user instantly without prompting for additional credentials.

---

Role-Based Access Control (RBAC) in SDDC Manager

While identity federation proves who a user is (authentication), Role-Based Access Control (RBAC) governs what that user is permitted to do (authorization). SDDC Manager enforces a strict RBAC security model to implement the principle of least privilege.

Predefined System Roles in SDDC Manager

SDDC Manager provides four immutable predefined roles tailored to common operational responsibilities:

Enterprise Directory Group Mapping

Best architectural practice strictly prohibits assigning SDDC Manager roles directly to individual user accounts. Individual assignments create administrative overhead and leave orphaned permissions when personnel change positions.

Instead, administrators map enterprise directory groups (from Active Directory or Entra ID) directly to SDDC Manager predefined or custom roles:

• Group AD\Cloud-Infrastructure-Admins ──> Mapped to Cloud Admin
• Group AD\Compute-Virtualization-Engineers ──> Mapped to Administrator
• Group AD\NOC-Operations-Team ──> Mapped to Operator
• Group AD\Compliance-Security-Auditors ──> Mapped to Viewer

When a security engineer joins the enterprise and is added to AD\Compliance-Security-Auditors in Active Directory, their permissions in SDDC Manager take effect immediately upon their next federated login. Conversely, removing the user from the Active Directory group immediately revokes their access across the entire VCF platform.

Multi-Plane Separation of Duties

Candidates must recognize the clear boundary between SDDC Manager RBAC and workload component RBAC:

• SDDC Manager RBAC: Governs the private cloud control plane (creating workload domains, commissioning physical hardware, orchestrating full-stack lifecycle operations, replacing system certificates).
• vCenter Server RBAC: Governs compute and storage virtualization objects (creating virtual machines, creating VM snapshots, configuring VM folders, managing datastore clusters).
• NSX Manager RBAC: Governs software-defined network fabrics and micro-segmentation (creating Tier-0/Tier-1 gateways, configuring distributed firewall / DFW rules, defining intrusion detection policies).

An administrator granted the Administrator role in SDDC Manager does not automatically receive full administrative control over NSX distributed firewall rules unless their directory group is also mapped to the Enterprise Admin role inside NSX Manager.