Authentication Mechanisms
To perform operations in the vSphere
environment, principals must authenticate to the
vSphere
Automation
services. You can use the default vCenter
Single Sign-On
identity source or federate your vCenter Server
to an external identity provider such as
Microsoft Active Directory Federation Services, Okta, or Azure AD.As a result from authenticating to the
vSphere
Automation
services, client applications and users receive a session identifier. You can choose from several supported authentication mechanisms to obtain a session identifier that grants you access to the vSphere
Automation
services in the virtual environment.Choosing Your Identity
Source
First, you must decide whether to
authenticate to
vCenter Server
by using
the default identity provider, vCenter
Single Sign-On
, or leverage your enterprise configuration to an external
identity provider.Default or External Identity
Provider
vCenter Server
acts as the default identity provider, by using its
built-in vCenter
Single Sign-On
service to
authenticate users and service accounts.In vSphere 7.0 and later, you can
delegate vSphere identity management to an external identity provider and take
advantage of increased security and multifactor authentication. In this scenario,
vCenter
Single Sign-On
is replaced by
an external identity provider as the entity that performs principals'
authentication.Identity provider federation enhances the
security and compliance of your applications and provides access to flexible
benefits such as multifactor authentication (MFA) and automatic account
synchronization.
You can federate
vCenter Server
authentication to:- AD FS (starting in vSphere 7.0)
- Okta (starting in vSphere 8.0 Update 1)
- Azure AD (starting in vSphere 8.0 Update 2)
For more information, see Identity Provider Federation for vCenter Server.
Basic or Token-Based
Authentication
You can use basic and token-based
authentication to authenticate principals to the
vSphere
Automation
services. VMware encourages you to use token-based
authentication as it provides more security and flexibility for your applications
and users.Basic Authentication
Basic authentication passes a user name
and password to
vCenter Server
.By default, principals can use the
vCenter
Single Sign-On
user name and
password to connect to the vSphere
Automation
endpoint. The vSphere
Automation
endpoint checks whether the user name and password are
present in the VMware Directory Service. On success, the system returns a session
identifier for the vSphere
Automation
endpoint.If your
vCenter Server
is federated to an external identity provider, you
can use basic authentication through the OAuth 2.0 Password grant type.VMware encourages you to refrain
from using basic authentication and adopt token-based authentication, as it is
more secure and provides more flexibility.
Token-Based
Authentication
Token-based authentication involves the
use of an encrypted token that provides authentication and authorization data to the
vSphere
Automation
endpoint. The vCenter Server
token complies with the Security Assertion Markup
Language (SAML) specification, an XML-based schema for communicating authentication
data.To acquire a SAML token, client
applications issue a token request to
vCenter
Single Sign-On
. Client applications then send the SAML token to the
vSphere
Automation
API endpoint in exchange for a session
identifier.Starting with vSphere 7.0, you can use
token-based authentication for your federated
vCenter Server
through a 3-step process:- Principals use the various OAuth 2.0 grant types with the external identity provider to obtain identity and access tokens in JSON Web Token (JWT) format.
- Principals exchange the JWT tokens for avCenter Single Sign-OnSAML token.
- Principals use the SAML token to obtain a session identifier from thevSphere Automationendpoint.
For code
examples of authentication with the various OAuth 2.0 grant types, see the
vsphere-automation-sdk-java
VMware repository at
GitHub.