Salesforce
Configuring the Veza integration for SFDC
Overview
The Salesforce integration discovers users, authorization entities (such as groups and permission sets), and data objects (accounts). Veza parses group memberships, role assignments, and account shares to show users with access to sensitive records, and reveal who is able to read, delete, or otherwise alter data and settings. Salesforce entities are fully integrated with Veza Search, Insights, and Workflows.
See Notes and Supported Entities for more information about discovered entities and properties.
Cross service connections
Veza automatically detects relationships between Okta identities and Salesforce local users.
If you have integrated another identity provider for single sign on, the provider configuration can include custom identity mappings to Salesforce.
Setup
To integrate Veza with Salesforce, you will need to:
Create a user, and grant the required API permissions by creating and assigning a permission set.
Create an SFDC Connected App Veza will use to make API calls. You can generate a private key and self-signed certificate for the Veza service application, or use an existing key pair.
Configure the Veza integration, providing the generated certificate, user email, and client id (key) for the Connected App.
The Salesforce account to discover must have API access enabled.
Create a Salesforce user
To conduct the API calls required for discovery, Veza will need a Salesforce user account.
If an appropriate service account user and permission set with API access enabled already exists, skip to Create a Connected App
To create the user:
In a browser, open the Setup section in Salesforce with an administrative account
In the left navigation pane, under the ADMINISTRATION heading, expand Users and click the Users link
At the top of the Users table, click New User
Enter details for the user account:
License: Use
Salesforce
Profile: Use a default profile, or create one. For new profiles, use the built-in role
Minimum Access - Salesforce
. Use the permission set in the next section to explicitly grant permissions.
See Add a user in the Salesforce documentation for more details.
Create Salesforce Permission Set
Next, grant the user the API permissions Veza will need to gather entity metadata and authorization information.
If an appropriate permission set for service accounts already exists, you can skip these steps and use an existing permission set.
As an administrator, browse to the Salesforce Setup section
In the left navigation pane, under the ADMINISTRATION heading, expand Users and click Permission Sets
At the upper left hand of the Permission Sets table, click New
Enter a Label and optional Description
The API Name field is automatically populated by the label but can be overridden if needed
Leave the License dropdown field set to --None--
Click Save to create the permission set
On the resulting permission set overview page, click System Permissions
Click Edit and enable the options:
API Enabled: this enables access to the Salesforce.com API
View All Profiles: required to gather user information
View All Users: required to gather user information
View Roles and Role Hierarchy: required to view role hierarchy for evaluating sharing
View Setup and Configuration: required to get object metadata
View Health Check: used to identify SaaS misconfigurations
At the top of the main pane, click Save
On the resulting permission set overview page, under Apps click Object Settings.
Click on the Accounts object.
Click Edit. Under Object Permissions, select Read permission.
For Product discovery:
Click on the Products object type. Click Edit and enable Read object permissions.
For Price Book discovery:
Click on the Price Book object type. Click Edit and enable Read object permissions.
For Opportunity discovery (Early Access):
Click on the Opportunities object type. Click Edit and enable Read and View All object permissions.
At the top of the main pane, click Save
Go back to the Permission Sets table, find the newly created permission set, and click on it.
From the details view, click Manage Assignments at the top of the main pane
Click Add Assignments at the top of the screen
Locate the user that will make API calls to the Salesforce endpoint, click the checkbox next to the account, and click Assign at the top of the table
Click Done
See Create Permission sets for more details.
Prepare a key and certificate for the Connected App
The Connected App uses an X.509 certificate for JWT-based OAuth 2.0 authentication. This certificate and its associated private key enable secure API access to Salesforce. You can either create a self-signed certificate or use an existing certificate.
Certificate Requirements:
Must be an X.509 certificate with client authentication capabilities (with the attribute
"Enhanced Key Usage": "Client Authentication"
)Must be in PEM format (both certificate and private key)
Can be either self-signed or CA-issued
Must include both the certificate (.crt) and private key (.key) files
To authenticate using a self-signed certificate:
Follow the Salesforce instructions to Create a Private Key and Certificate to create a key pair.
Save both files:
The
.crt
for uploading to SalesforceThe
.key
for configuring Veza
If you already have a key and certificate pair to use, you can skip this step and upload the certificate when creating a connected app, provided it meets the requirements above. Upload the private key when configuring the Veza integration.
Create a new Connected App
To add a Salesforce app for Veza, open the Salesforce Setup section.
Under the Platform Tools heading, expand Apps, and click App Manager. Click New Connected App at the upper right corner.
Under the Basic Information heading, complete the following:
Connected App Name: a unique name for the application (ex: Veza Salesforce)
API Name: this will be automatically populated by the app name, but can be overridden
Contact Email: enter a valid email for you or your team
Under the API (Enable OAuth Settings) header, click the checkbox to Enable OAuth Settings
Click the checkbox for Enable for Device Flow
In the Callback URL field, enter
https://localhost
(a callback URL is not used for device flow)Click the checkbox for Use digital signatures and upload the
.crt
file for the client certificateIn the Selected OAuth Scopes field, add the following two scopes by highlighting them and clicking >
Full access (full) to grant access to data accessible by the logged-in user. Actual permissions are still restricted by the applied permission set.
Perform requests at any time (refresh_token, offline_access)
Click Save at the bottom of the page
Click Continue to create the Connected App
See Create a Connected App for more details.
Apply Permission Set to the Connected App
From the Salesforce Setup page, under the PLATFORM TOOLS, click Apps > App Manager.
Locate the newly created Connected App, click the drop-down arrow next to its name, and click View
Click Manage Consumer Details and copy the Consumer Key and close the tab
At the top click Manage to update the policies associated with the Connected App
Click Edit Policies
Set Permitted Users to Admin approved users are pre-authorized
Set IP Relaxation to Relax IP restriction. Otherwise, you can set this to allow the Veza tenant or Insight Point IP range.
Click Save
Under Permission Sets click Manage Permission Sets and assign the one you just created.
It make take up to 10 minutes for Salesforce to full propagate the configuration. After this finishes, the Salesforce account is ready to add to Veza.
Adding the integration to Veza
Open Veza Integrations page.
Click Add Integration. Pick Salesforce and click Next.
Enter the required information, then click Create Integration:
Name
Unique name to identify the SFDC provider
Domain
SFDC domain (such as org-dev-1
)
User Name
Salesforce user name
to connect as
Consumer Key
Consumer key (client id) of the connected app (SFDC App Manager > select connected app > View > Manage Consumer Details)
Auth Certificate
Upload the key for the SFDC app (.pem
or .key
format
Salesforce Sandbox Deployment
Select if connecting to a Salesforce Sandbox org. Clear if connecting directly to the production domain.
Object Allow List
Comma separated list of object (account) names to allow for discovery
Object Deny List
Comma separated list of objects to deny for discovery
License Allow List
Comma separated list of license names to filter profiles and users
License Deny List
Comma separated list of license names to filter profiles and users
The domain should not include the full Salesforce URL. For example, if an SFDC URL is
https://org-dev-1.my.salesforce.com/
, the domain isorg-dev-1
.
Discover only users and IAM entities by adding all objects to the deny list by entering a wildcard
*
.Exclude users by license type by adding entries to the configuration's license deny or allow lists. Possible SFDC licenses include
Knowledge Only User
(users who only have access to the Salesforce Knowledge app) andExternal Identity
(intended for customers and partners).
Supported entities
The integration currently supports the following entity types:
Salesforce Organization
Salesforce User
Salesforce Group
Salesforce Role
Salesforce Profile
Salesforce PermissionSet
Salesforce Object
Salesforce Account
Salesforce Account Share
Salesforce Price Book
Salesforce Product
Account Shares define who is allowed to view or edit records owned by another user.
Entity properties
The following entity types and properties are available to filter results throughout the Veza interface:
User
Is Active
Boolean if user is active
User
Last Login At
User last login time if available
User
User Type
The category of user license for the user.
User
manager_id
Salesforce ID of user manager if set
User
ExternalUser
If User is external
User
UserLicense
License Attributes
, ID
, LicenseDefinitionKey
, Name
, MasterLabel
Group
Type
Group type
Group
Owner Id
User ID of Group owner
Account
Attributes
type
and URL
of the SFDC object
Account
Name
SFDC Account name
Account
OwnerId
User ID of the account owner
Account
ParentId
Parent object ID
Account
Domain
SFDC Domain for the account
Account
Shares
Account Share details: TotalSize
, Done
, Shares
Account Share
AccountId
ID of the Account associated with the share
Account Share
UserOrGroupId
ID of the User or Group granted access
Account Share
AccountAccessLevel
Level of access granted (READ, EDIT, ALL)
Account Share
RowCause
Reason that this sharing entry exists
Account Share
Domain
Account share domain
Limitations
Groups: Veza discovers the following group types: Organization
, Role
, RoleAndSubordinates
, RoleAndSubordinatesInternal
, and Regular
, along with AllCustomerPortal
and Queue
;
Organization
public group including all User records in the organization.Role
public group including all User records in a particular UserRole.RoleAndSubordinates
public group including all the User records in a particular UserRole, and all the User records in any subordinate UserRole.RoleAndSubordinatesInternal
Represents internal roles and their subordinates in the org’s role hierarchy, excluding customer and partner roles.Regular
Standard public group (typically user-created).AllCustomerPortal
includes all members with a customer portal license excluding high volume licenses.Queue
is typically used to assign a single record to many individual users
Licenses: For the AllCustomerPortal
license, Veza currently supports the following license types:
PID_Customer_Portal_Basic
PID_Customer_Portal_Standard
PID_Limited_Customer_Portal_Basic
PID_Limited_Customer_Portal_Standard
PID_Overage_Customer_Portal_Basic
POWER_SSP
Veza excludes all High Volume Customer Portal
licenses, since these are not included in the AllCustomerPortal
group. An example high volume license is: PID_Overage_High Volume Customer Portal
.
Account Licenses are not currently included in effective permissions (users may not have a license to access a resource they would otherwise have permissions on).
Permissions: Permissions granted by group types such as ManagerAndSubordinatesInternal
, ChannelProgramGroup
, PRMOrganization
, and others are not currently supported. See member roles for more details on built-in roles and usage.
Last updated