VMware Identity Broker - vCenter Server

This API Reference provides documentation, descriptions, and request and response samples for the VMware Identity Broker REST APIs for vCenter Server.

What is VMware Identity Broker

VMware Identity Broker is a built-in container within vCenter Server that you can use for identity federation to an external identity provider. With VMware Identity Broker, you configure a connection to an external identity provider, which you can then use to authenticate principals to vCenter Server. The users and groups from your identity source are pushed to your vCenter Server by using the SCIM 2.0 standard. Once configured, VMware Identity Broker functions as an authorization server for all your connected apps, scripts, and solutions.

vCenter Server Versions and Coverage

Starting with vSphere 8.0 U1, you can use VMware Identity Broker to federate your vCenter Server to an external identity provider. You can federate your vCenter Server to the following external identity providers by using VMware Identity Broker:

Okta (starting in vSphere 8.0 update 1)
Azure AD (starting in vSphere 8.0 update 2)

VMware Identity Broker Configuration

For more information on how to configure your vCenter Server to use VMware's Identity Broker, see: - Configure vCenter Server Identity Provider Federation for Okta

Configure vCenter Server Identity Provider Federation for Azure AD

VMware Identity Broker API Use Cases

For use cases with vCenter Server and the VMware Identity Broker's APIs, see the Authentication Mechanisms chapter in the VMware vSphere Automation REST API Programming Guide.

OAuth 2.0 and OIDC

The vSphere implementation of VMware Identity Broker services uses the OAuth 2.0 authentication framework and the OpenID Connect (OIDC) authorization protocol. If your vCenter Server is configured to use VMware Identity Broker as the authorization server, you can authenticate your users and apps by using the different OAuth 2.0 grant types: authorization code, client credentials, password and refresh token. For authentication use cases, see the Federated Authentication chapter in the VMware vSphere Automation REST API Programming Guide.

Request Failures

API errors are reported using standard HTTP status codes.

HTTP 4XX codes are returned when the request contains bad syntax or cannot be fulfilled
HTTP 5XX codes are returned when something is wrong with the server

Authorization errors will be denoted by either HTTP 401 (Unauthorized) or HTTP 403 (Forbidden). These kinds of errors are usually access token related and can be cleared by making sure that the token is present and has not expired.

An API will return HTTP 444 (No Response) (with no response body) when the request's Host header does not match the server's fully qualified domain name.

For all errors the API's response body includes the error code and additional error message in the format below:

"errors": [
    {
        "code": "oauth2.client.with.client.id.already.exists",
        "message": "OAuth2 Client with client id {client_id} already exists.",
        "parameters": {
            "oauth2_client_id": "{client_id}"
        }
    }
]