Courts want Workspace ONE Access to use OpenID Connect against a statewide identity platform. Which settings belong on the Access identity-provider object?
Select an answer to reveal the explanation.
Short Explanation
OIDC is a named handshake: client ID, secret, and the discovery URL go on the Access IdP object, same as filling in the statewide portal’s app registration. A CB API secret, a GI UUID, or an ACC enrollment token is a different product’s paperwork.
Full Explanation
Courts want Workspace ONE Access to use OpenID Connect against a statewide identity platform. Configure OIDC client ID, client secret, and the provider discovery URL on the Access identity-provider object—the same paperwork you fill in on the statewide portal’s app registration. Using only a Carbon Black API secret and an NSX-T Manager virtual IP fails by concept because those artifacts belong to endpoint registration and NSX management networking, not OIDC client configuration for Access. Using a Guest Introspection service virtual machine UUID as the OIDC issuer fails because a GI SVM UUID is not an OpenID Connect issuer and does not replace discovery metadata. Using an AirWatch Cloud Connector enrollment token in place of OpenID Connect fails because ACC tokens enroll UEM connectors and are a different product handshake than OIDC. Exam caveat: Access OIDC IdP objects require client ID, client secret, and discovery URL—not CBC API secrets, NSX Manager VIPs, GI UUIDs, or ACC enrollment tokens. Operational check: register Access as an OIDC client in the statewide platform, enter client ID, client secret, and discovery URL on the Access IdP object, complete a court user login test, and store secret-rotation and discovery-URL change procedures in the courts IdP runbook. Validate that Access can reach the discovery endpoint before cutover so misrouted DMZ rules do not block OIDC metadata.