Workday

Configuring the Veza integration for Workday HCM

This document provides instructions for configuring a Workday tenant to enable the Veza integration.

Overview

The Veza integration for Workday Human Capital Management (HCM) enables search, workflows, and insights to show who can take privileged actions within Workday. After configuring the integration, you can use Search, Insights, and Workflows to:

• Find the Domain and Business Policies that belong to each security group

• Find the Permissions granted by Workday Security Policies

• Conduct user access reviews using Workday as an identity source

By default, this connection is read-only. To enable provisioning capabilities and email write-back, see the Enable Lifecycle Management section.

Veza will discover the following entities:

• Workday Tenant

• Workday Worker

• Workday Account

• Workday Security Group

• Workday Domain Security Policy

• Workday Business Process Security Policy

See notes and supported entities for more details.

Workday configuration

Prerequisites:

• You will need an x509 certificate and private key for API client registration and configuring the Workday provider in Veza. The integration utilizes the private key file, with the certificate configured on the Workday API Client. To create a certificate, see our OpenSSL guide, or use an existing signed certificate and key pair.

• Verify that Oauth2 authentication is enabled for the Workday tenant. On your Workday instance, enter Tenant Setup, then pick Security and click Edit. Find OAuth 2.0 Settings and check the box OAuth 2.0 Clients Enabled.

1. On your Workday instance, type Register API Client to add an API client.

   1. Enter a name for the client

   2. For Client Grant Type pick Jwt Bearer Grant

   3. Enable the Enforce 60 Minute Access Token Expiry to align with best practice

   4. Choose to “create a new x509 public key”

   5. Paste the text of the PEM-encoded Certification file containing the public key. (starting with -----BEGIN CERTIFICATE----- and ending with -----END CERTIFICATE-----)

   6. For Scope (functional areas), enter:

      • System

      • Staffing

   7. Click OK to create a API client and save the client ID for later.
2. On your Workday instance, type View API Clients to retrieve the endpoint URL for the API client you just created. Copy the Workday REST API Endpoint URL (it will look like this https://wd5-services1.myworkday.com/ccx/api/v1/veza). Save the URL for configuring the integration in Veza.

3. On your Workday instance, type Create Integration System User to create a user for Veza. After creating it, copy the username for later.

4. On your Workday instance, type Create Security Group to add a security group

   1. For Type of Tenanted Security Group, pick Integration System Security Group (Unconstrained)

   2. Enter a name for the security group and click OK to create it.

   3. On the Edit Integration Security Group (Unconstrained) screen, add the Integration System User to the group under Integration System Users. You can search or browse for the appropriate user. Click OK to add it.
5. On your Workday instance, search for Maintain Permissions for Security Group to apply the necessary permissions for the security group.

   1. For Operation, pick Maintain.
   2. For Source Security Group, enter the name of the security group you created earlier.

   3. Click OK to open the edit form.

   4. On the next screen, under Domain Security Policy Permissions, add a separate row for each required Domain Security Policy. To add a new row click the + icon, enter the correct access level and the Domain Security Policy. Add the Domain Security Policy according to the following table.

   5. Click OK, review the permissions and click Done.
6. Activate the security policy changes on Workday. If you don’t activate the security policy changes, Veza will not be able to extract the data from Workday:

   1. On your Workday instance, type Activate Pending Security Policy Changes and pick Tasks & Reports > Activate Pending Security Policy Changes.

   2. Add a descriptive comment and click OK.

   3. Review the pending security policy changes, click the Confirm checkbox, and click OK.

Domain security policy permissions: To gather entities and attributes, the Veza service principal must have the following permission scope:

Access	Policy
View and Modify	Workday Query Language
Get Only	Person Data: Work Email
Get Only	Worker Data: Current Staffing Information
Get Only	Worker Data: Staffing
Get Only	Person Data: Work Email
Get Only	Security Configuration
Get Only	Business Process Administration
Get Only	Integration Security

The following screenshot shows all required permissions. If you encounter issues with the integration, ensure that the inherited permissions are as shown:

Expected domain security policy permissions in Workday

Enable Lifecycle Management

Early Access: Lifecycle Management capabilities are experimental features. Contact our support team to enable this functionality for your platform.

When configuring a Workday integration in Veza, tick the Allow Provisioning box to make the integration an eligible provider for Lifecycle Management. When creating Provisioning Rules and Policies, administrators will be able to pick the Workday tenant as the provisioning source. When Veza connects for extraction, changes to user attributes will trigger lifecycle management actions based on the active Policies and Mapping Rules.

Permissions for Lifecycle Management

After creating an email address for a newly-provisioned user, Veza can update the original Workday profile with the new address.

To prevent errors when writing back email addresses, the security group must have additional permissions:

Access	Policy
View and Modify	Workday Query Language
View and Modify	Person Data: Work Email
View and Modify	Person Data: Work Contact Information
View and Modify	Worker Data: Staffing
View and Modify	Worker Data: Public Worker Reports
Get Only	Security Configuration
Get Only	Business Process Administration
View and Modify	Security Administration
View and Modify	Workday accounts

The Workday API client must have the scopes:

• Staffing

• Contact Information

• System

• Tenant Non-Configurable

See Enable Provisioning for Workday to grant the additional capabilities with a segmented security group.

Configuring the Workday integration in Veza

To register the integration in Veza, log in as a user with the administrator role, and go to Integrations > Add Integration.

1. Pick Workday for the integration type and click Next.

2. Enter a Name to identify the integration.

3. Enter the REST API Endpoint URL, retrieved in step 4 above after configuring the Workday API client.

4. Enter a Client ID from step 2.

5. Upload a Private Key: this is the certificate's private key in .pem format.

6. Enter the Workday integration system user (ISU) Username created in step 5.

7. (optional) Add identity mapping configurations to correlate Workers to identities in an integrated Identity Provider.

8. Save the configuration to queue the first extraction.

Custom Properties for Workday

To discover custom attributes your organization applies to Workers in Workday, define them by name and type on in the Custom Properties section of the integration configuration.

1. On Edit Integration > Custom Properties tab, click Add Custom Property.

2. Name: Enter the name of the custom attribute on the Workday object, e.g. my_custom_property

3. Type: Specify how Veza should handle the contents of the field. Supported types are:

   • String

   • Number

   • Boolean

   • RFC339 Timestamp

   • String List

4. Save the configuration.

These properties are added to Veza's query on the allWorkers table via WQL. The custom attributes will appear in Authorization Graph after the next sync, enabling Lifecycle Management actions and filters for Search, Rules, and Access Reviews based on the values.

Identity mapping configurations for Workday

Associating Workday Workers with IdP identities, and IdP identities with Workday Accounts enables search and visualization of relationships such as:

• Workday Worker -> Okta Identity -> Workday Account -> Domain Security Policy

• Workday Worker -> Microsoft Azure AD Identity -> Snowflake Local User -> Snowflake Effective Permissions

To configure these identity mappings, you will need to integrate your identity provider. Then, edit both integrations to add a custom mapping based on matching unique ID or email:

1. Edit the Workday integration, and add a mapping configuration. Select your Identity Provider for the destination data source type.

2. Edit the integration for your IdP, and add a mapping configuration. Select "Workday Iam" for the destination data source type.

Notes and supported entities

The integration includes Saved Queries to identify:

• Workday Security Groups not containing any Workday Account

• Workday Security Groups with no active Workday Account

• Activated Workday Accounts with no log-ins in the last 90 days

• Workday Accounts with Implementer user flag enabled

• Workday Accounts with Developer user flag enabled

The following entity types and attributes are discovered:

Workday Tenant

The tenant is the top-level entity representing an organization's Workday environment.

Workday Worker

Workers are records for employees within Workday. A worker might or might not have a Workday Account.

Veza handles Workers as a separate data source, to enable two different identity mappings:

• From Workday Worker to Identity Provider user

• From Identity Provider user to Workday Account

Workday Worker entity attributes:

• BusinessTitle

• CostCenter

• EmployeeID

• EmployeeTypes

• Gender

• HireDate

• IsActive

• Location

• ManagementLevel

• Managers

• Position

• TerminationDate

• WorkdayID

Workday Account

A local account used to access modules, reports, and modify data related to Workers in Workday

An account might or might not be associated with a Worker profile. Workday Account entity attributes:

• EMail

• CreatedAt

• UpdatedAt

• UserLastLoginAt

• UserIsActive

• UserIsLocked

• PasswordLastSet

• PropDoNotAllowUISessions

• PropPasswordExpired

• RoleName

• IsDeveloper

• IsImplementer

• Username

Workday Security Group

Security Groups manage permissions for users in Workday. They can be role-based or user-based:

• Role Based Security Groups - Collections of users with security groups assigned to them because of their Role

• User Based Security Groups - Collections of users with security groups directly assigned to their profiles

Within Veza, Policy Binding entities connect Security Groups to Business process and Domain security policies.

Workday Security Group attributes:

• Comment

• SecurityGroupType

• WorkdayOwned

Workday Policy Binding

In Workday, security policies define permissions to securable objects such as reports, tasks, and business processes.

In the Veza Authorization Graph, policy binding entities for Workday show the scope of permissions an identity has to a Domain or Business Process Security Policy (such as Get, Put, or View,)

Setting Workday Policy Binding as the destination entity type for a Workflow query enables review of permissions for each identity of the source entity type (such as Workday Account).

Workday Domain Security Policy

Domain Security Policies control access to reports, tasks, and integrations.

Workday Domain Security Policy entity attributes:

• CreatedAt

• UpdatedAt

• UserIsActive

• Description

• FunctionalAreas

Workday Business Process Security Policy

Business Process Policies are used to secure business process objects in Workday.

Workday Business Process Security Policy entity attributes:

• CreatedAt

• UpdatedAt

• Description

• DynamicBusinessProcess

• AttachmentsEnabled

• FunctionalAreas