Delegated Authentication for Veeva CRM

  • iPad
  • iPhone

Veeva CRM supports delegated authentication, or single sign-on (SSO), allowing users to sign into Veeva CRM with third-party credentials. Customers must set up a delegated authentication endpoint with their identity provider (IDP; for example, Okta or PingFederate).

To configure delegated authentication in Salesforce:

  1. Navigate to the Single Sign-On Settings.
  2. Select Edit.
  3. Select Disable login with Salesforce credentials.
  4. Select Save.
  5. Select Edit.
  6. Enter the URL of the IDP’s delegated authentication endpoint in the Delegated Gateway URL field.
  7. Select Save.
  8. Navigate to the appropriate end user profiles.
  9. Select Edit.
  10. Select the Is Single Sign-On Enabled check box in the Administrative Permissions.

In this diagram, the flow of information begins with the user entering a username and password on the offline device (iPad or Windows) Those credentials are then sent to the Identity Provider ,who then returns the Salesforce username and token. This is sent to the Vod server and then to SFDC. When SFDC recognizes the user is SSO-enabled, they forward the credentials to the Delegated Authentication Endpoint. Delegated Authentication Endpoint authenticates the credentials and responds either yes or no. Depending on the response, the offline device receives the response and either logs in the user or gives an error.

Using Token Authentication

To provide greater security, customers can implement a security token service (STS) in addition to delegated authentication. Implementing an STS ensures passwords are only sent to endpoints controlled by the customer.

If an STS is implemented, when a user signs into the Veeva CRM app, their username and password are first sent to the customer-hosted STS, which returns a token to Veeva CRM. Veeva CRM then uses the username and token to verify the signin with Salesforce and the delegated authentication endpoint. Customers must set up the endpoint to authenticate a username and token instead of a username and password.

The authentication exchange between the Veeva CRM app and a customer’s STS is based on SOAP web services and the WS-Trust standard. The Veeva CRM sends a request security token (RST) message to the STS and receives a request security token response (RSTR) message back. The security token is then extracted from the response message and passed to Salesforce for verification.

Documentation for WS-Trust is found on the OASIS open standards website ( and includes:

The exchange of information is shown in the following diagram:

To enable delegated authentication with STS for Veeva CRM for iPad in your org:

  1. Implement a security token service (STS) that can receive request security token (RST) messages and return request security token response (RSTR) messages based on WS-Trust.
  2. Ensure Salesforce delegated authentication is enabled for your org.
  3. Configure the MDM with the endpoint URL for the RST and RSTR messages and the Delegated Gateway URL configured in Salesforce. Both URLs must be accessible via the internet. See Delegated Authentication for Veeva CRM via MDM for more information.

The following is an example RST Veeva CRM sends to the STS at the endpoint URL specified by the customer:

<?xml version="1.0"?>

<soapenv:Envelope xmlns:xsd="" xmlns:xsi="" xmlns:soapenv="">


    <wsse:Security xmlns:wsse="" soapenv:mustUnderstand="1">

      <wsu:Timestamp xmlns:wsu="">




      <wsse:UsernameToken xmlns:wsu="" wsu:Id="usernameToken">


        <wsse:Password Type="">corp_directory_password</wsse:Password>



    <wsa:Action xmlns:wsa="" xmlns:wsu=""></wsa:Action>


  <soapenv:Body xmlns:wsu="">

    <wst:RequestSecurityToken xmlns:wst="">



      <wsp:AppliesTo xmlns:wsp="">

        <wsa:EndpointReference xmlns:wsa="">






        <wsse:SecurityTokenReference xmlns:wsse="">

          <wsse:Reference URI="usernameToken" ValueType=""/>






The following is an example RSTR Veeva CRM expects back from the STS.  The entire security token is extracted from the message, base64 encoded, and sent to Salesforce in the signin request sent by CRM.

<S11:Envelope xmlns:S11="">


<add:To xmlns:add=""></add:To>

<add:Action xmlns:add=""></add:Action>

<wsse:Security S11:mustUnderstand="1" xmlns:wsse="">

<wsu:Timestamp wsu:Id="4ad9d92b-dd36-4ae7-a372-a82ee0d4b213" xmlns:wsu="">







<ns:RequestSecurityTokenResponseCollection xmlns:ns="">




<saml:Assertion ID="_mdqaUZ4BWj_672ve1bznz6Vu.t" IssueInstant="2012-09-17T09:38:04.108Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">


<ds:Signature xmlns:ds="">


<ds:CanonicalizationMethod Algorithm=""/>

<ds:SignatureMethod Algorithm=""/>

<ds:Reference URI="#_mdqaUZ4BWj_672ve1bznz6Vu.t">


<ds:Transform Algorithm=""/>

<ds:Transform Algorithm=""/>


<ds:DigestMethod Algorithm=""/>










<wsse:SecurityTokenReference xmlns:wsse="">

<wsse:KeyIdentifier ValueType="">7G/+BJtRSRRfmmo3JfbuDx+f+TY=</wsse:KeyIdentifier>





<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified"></saml:NameID>

<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"/>


<saml:Conditions NotBefore="2012-02-17T22:43:04.233Z" NotOnOrAfter="2012-02-17T22:53:04.233Z">





<saml:AuthnStatement AuthnInstant="2012-02-17T22:48:04.108Z" SessionIndex="_mdqaUZ4BWj_672ve1bznz6Vu.t">








<wsu:Created xmlns:wsu="">2012-08-15T22:48:04.108Z</wsu:Created>

<wsu:Expires xmlns:wsu="">2012-08-15T23:18:04.108Z</wsu:Expires>



<wsse:SecurityTokenReference wsse11:TokenType="" xmlns:wsse="" xmlns:wsse11="">

<wsse:KeyIdentifier ValueType="">_mdqaUZ4BWj_672ve1bznz6Vu.t</wsse:KeyIdentifier>