This article provides an overview of identity provider support, capabilities, and requirements.
Vault File Manager supports the following identity providers:
- Ping Identity
- Microsoft Azure™ AD
How Authentication Works
Vault File Manager authentication works by:
- Consuming Authorization Server (AS) metadata retrieved from a Vault profile to allow users to authenticate with the AS via OAuth 2.0 / OpenID Connect or with Vault directly via username and password.
- Requesting the Vault session based on the
- Allowing Vault to validate tokens locally if they are presented as JWT when the keys are published via the JWKs URI.
- Allowing Vault to validate tokens remotely using the introspection endpoint, if exposed by the AS.
Note: Beginning in 19R1.4, if you have “Ping” or “Other” selected in your OAuth 2.0 / OpenID Connect profile, we recommend that you update your redirection URI in your Authorization Server to com.veeva.vaultfilemanager://authorize. It is not recommended to continue using dynamic redirect URIs. Contact your Customer Success Manager for more information.
Vault File Manager supports:
- OAuth 2.0 / OpenID Connect with no client secret.
Authorization Codegrant type with
- Silent refresh of the Vault session if the AS honors the
offline_accessscope and presents a
- Federation based on the user’s Federated ID or Vault User Name.
- Modern Windows Authentication (ADAL) to authenticate with Microsoft ADFS, when configured.
Vault File Manager requires:
- The user’s Federated ID to be included in the
subclaim of the token. Customers can configure an alternative identifier claim if the
subclaim is not available or cannot be modified to contain the correct Federated ID.
- The AS to support the hard-coded client ID. Customers can create a mapping between the hard-coded client ID stored in the client apps, such as Vault File Manager, and the generated client ID required by the AS.
Note: Veeva Vault Platform strongly advises that Authorization Servers support PKCE.