Skip to content

VMware vCenter

Britive integrates with VMware vCenter Server through the Britive Access Broker. vCenter has a fundamentally different identity model than standalone ESXi: there is no local-account-creation API on the box. Authentication goes through vCenter Single Sign-On, with users coming from either the local SSO domain (vsphere.local) or a federated identity source (AD, LDAP, ADFS, OIDC).

The realistic JIT pattern is therefore role grant on an existing identity — not “create a temp user.” On checkout, Britive grants the requestor’s existing SSO/AD identity the Administrator role at the vCenter root folder. On checkin, the role binding is removed.

Access Patterns

PatternWhat it does
JIT vCenter AdminOn checkout, grants the Administrator role at the vCenter root folder (group-d1) to the requestor’s existing SSO/AD principal. On checkin, removes the role binding. The requestor signs in to vCenter with their usual identity — there are no ephemeral credentials to hand back.

Why not “create a temp vCenter user”? vCenter SSO does have an admin API for local SSO accounts at /sso-adminserver/sdk/vsphere.local, but most customers federate SSO with AD and rotate there. The role-grant pattern works for both local SSO and federated identities, so it’s the universal template.

Tested Versions

AttributeValue
PlatformVMware vCenter Server
Tested versionsvCenter 8.0
APIvSphere SOAP at https://<vcenter>/sdk
PortTCP 443 from broker to vCenter
AuthvCenter SSO (local vsphere.local or federated AD/LDAP/OIDC)
Broker runtimepython3 3.8+ (standard library only)

Scoping Beyond the Root

SetEntityPermissions works at any inventory level — root folder, datacenter, cluster, individual HostSystem — so customers needing narrower scope can adapt the entity MOID in checkout.py. The default (group-d1, the vCenter root, with propagate=true) gives full vCenter Administrator and is the simplest starting point.

In This Section

Last updated on