Delegated authentication is similar to Single Sign-on (SSO) in that it allows users to access multiple applications without having to log in separately to each one. Vault delegated authentication provides SSO functionality by allowing a user who has already logged in to a participating application to access Vault without logging in again.
Delegated authentication is a lighter weight SSO alternative to SAML because it does not require the overhead of an identity provider as an intermediary between the two systems. However, it is not as flexible as SAML because it requires the user to have an active session in a participating application first, and to use that session to establish a Vault session.
Delegated authentication is a good fit for scenarios where the user is primarily working one of the participating applications and is using Vault as a supporting document repository. One example is a call center user who uses Salesforce Service Cloud as a front-end, integrated with Vault as the back-end document repository. Vault documents could be displayed directly in the Salesforce UI using the Vault API and delegated authentication. Delegated authentication in Vault currently works with Salesforce.com/Veeva CRM.
Key Concepts
- Delegated authentication is enabled per security policy. It does not replace the user’s Vault password, but provides an alternative mechanism to establish a Vault session.
- Only active Vault users with valid passwords can use delegated authentication. Disabled users, locked users (due to password failures), and users with expired passwords cannot access Vault via delegated authentication.
- In technical terms, delegated authentication allows an active salesforce.com session to be used by Vault to establish a corresponding Vault session. The mechanism for triggering this is to send a URL for the desired Vault page or document, and include several URL querystring parameters that provide the required session context.
Configuring Authentication with Salesforce.com
Note: In their Spring ‘18 release, Salesforce announced a critical update of removal of instance names from URLs for Visualforce. Vault fully supports the changes detailed in this critical update.
Delegated authentication via Salesforce establishes a 1 to 1 relationship between Vault and a Salesforce.com / Veeva CRM org. For customers that have multiple Salesforce.com orgs and Veeva Vault instances, this is an implementation consideration. Furthermore, it requires a 1 to 1 relationship between user in the participating application and a Vault user. This means, for example, that you cannot associate multiple Salesforce.com users with a single Vault user. You also cannot associate multiple Vault users with a single user in the participating application, for example, you cannot have a Salesforce.com user who has delegated authentication in a production Vault and also in a testing or pre-release Vault.
To configure delegated authentication with salesforce.com:
- Turn on the Allow login via salesforce.com checkbox in one or more security policies. Enter the 18-digit Salesforce Organization ID for your Salesforce.com Org. You’ll need to convert the 15-digit Salesforce ID. There are many online tools that accomplish this.
- If your Vault user names and salesforce.com user names are the same, no further configuration is required. If your user names are different, provide the Salesforce user name for each Vault user that will be using delegated authentication.
- Refer to the Vault API documentation for details on configuring the URL for accessing Vault pages and documents via delegated authentication.