Workday Deployment Guide Version 4.0
Deployment Guide Overview
SAML Configuration
Workday­Driven IT Provisioning Overview
Basic Provisioning Configuration
Workday Provisioning Groups
Real Time Sync
Attribute Mappings and Active Directory
Deployment Guide Overview
top
Workday Overview
Okta integrates with Workday, an on­demand human capital management (HCM) and financial management software vendor, to provide a
comprehensive identity and access management solution. Okta automates provisioning in all leading cloud and web applications. With
Workday­driven IT provisioning, Okta can drive the worker life cycle of new­hire, update, termination, and rehire to downstream
applications from events that originate in Workday.
This guide provides instructions for configuring SAML authentication and Workday­driven IT provisioning between Okta and Workday. All
instructions and screen captures are for Workday v. 23.
Okta Overview
Okta is an enterprise­grade, identity management service built for the cloud, but it is compatible with many on­premises applications. With
Okta, IT can manage any employee's access to any application or device. Okta runs in the cloud, on a secure, reliable, and extensively
audited platform, which integrates deeply with on­premises applications, directories, and identity management systems.
SAML Configuration
top
Prerequisites
In Okta
Before you configure SAML, you must configure the Workday URL in Okta. To do this, first identify the Workday login URL, for example,
https://impl.workday.com/okta_pt1/login.flex. Next, truncate the URL after the tenant name. In this example, the tenant name is okta_pt1,
so the resulting value is https://impl.workday.com/okta_pt1. Then sign into Okta as an admin and navigate to the Workday app
configuration. Finally, navigate to the General tab> Your Workday site URL and paste in the truncated URL (e.g.,
https://impl.workday.com/okta_pt1).
Note: Your URL may look different from the one above. Workday offers several different types of instances—implementation, sandbox,
and production—and each has a slightly different domain name pattern.
SAML Setup
In Workday
In your Workday instance, sign in as the Workday administrator. In the search bar, type “edit tenant security”. Select Edit Tenant Setup –
Security from the search results, as shown in
Figure 1, to access the SAML configuration page.
Figure 1: Navigating to the SAML configuration page.
Granting access to edit a SAML configuration
If you do not see the Edit Tenant Setup – Security option in your search, this indicates that the user needs to be explicitly granted access
to modify the security settings.
1. In the search bar, type “domain security policies for functional area” and click the appropriate link.
2. In the search bar that prompts for Functional Area, type “system” or select System from the drop down menu. Click the OK
button.
3. You will see the following screen. Navigate down to Set Up: Tenant Setup – General and expand the list to select Set Up:
Tenant Setup – Security.
Figure 2: Granting access to configure SAML.
1. In the right­side pane, you will see a list of security groups that have been granted access. You can either add the desired admin
to one of the existing security groups, or add the appropriate security group to the list via the Edit Permissions button.
Configuring SAML in Workday
To configure SAML, you must populate various fields in Workday with custom values provided by Okta.
Sign into Okta
To sign in, do the following:
1. Navigate to the Workday app, then click the Sign On tab.
2. Under Settings, click the Edit button, and select the SAML 2.0 radio button.
3. Click View Setup Instructions. The instructions contain custom values that are unique to your Okta org and must be entered in
Workday.
Sign into Workday
Navigate to the Edit Tenant Setup page by typing “edit tenant setup” in the home screen search box, then clicking the Edit Tenant Setup
– Security link in the search results.
To complete the configuration:
1. Navigate to the Single Sign­On section.
2. Click the plus icon under Redirection URLs to add a new configuration.
3. Input “[org URL]/login­saml2.flex” into Login Redirect URL (replace [org URL] with your Workday URL). Example:
https://impl.workday.com/acme/login­saml2.flex.
4. Input “[org URL]/login­saml2.flex” into Mobile Redirect URL (replace [org URL] with your Workday URL). Example:
https://impl.workday.com/acme/login­saml2.flex.
5. Paste the Okta tenant URL into the Logout Redirect URL field (refer to your Okta instructions for the custom value). Example:
https://myorg.okta.com.
6. Select an Environment from the drop­down menu.
7. Navigate to the SAML Setup section and select the Enable SAML Access checkbox.
8. Click the plus icon underneath SAML Identity Providers to add a new configuration.
9. Create a name to identify your IdP in Identity Provider Name.
10. Paste the 20 character identifier into Issuer (refer to your Okta instructions for the custom value). Example:
kzx35tiTKLLBQXXGQATA.
11. Click the icon next to the x509 Public Key field, select Create from the left­hand column, and select Create x509
Certificate from the right­hand column. This will bring you to the Create x509 Certificate screen.
1. Enter a unique name for your certificate, for example, okta.cert. Refer to your Okta instructions for the custom values
required in steps b­d.
2. Paste the certificate’s start date into the Valid From field.
3. Paste the certificate’s end date into the Valid To field.
4. Paste the Okta certificate into the Certificate field.
5. Click the OK button to save your certificate.
12. Create a name for the Service Provider ID.
13. Paste the Okta SAML URL into the IdP SSO Service URL field (refer to your Okta instructions for the custom value).
14. Okta recommends checking Enable SP Initiated SAML Authentication.
Note: This step is optional.
1. Click the OK button to save your changes.
Figure 3: Configuring SAML in Workday.
IdP and SP­initiated behavior with Workday
Workday SAML supports both service provider (SP) initiated and identity provider (IdP) initiated SAML flow:
In an IdP­initiated SAML scenario, a user first logs into Okta. Next, the user clicks the Workday chiclet on the Okta dashboard.
Okta generates a SAML assertion and sends it to Workday; now the user can get into Workday.
In an SP­initiated SAML scenario, a user attempts to sign into Workday first (typically through a deep link). If a Workday session
exists, the user gets in. If it does not exist, Workday redirects the user to Okta. After the user successfully authenticates against
Okta, Okta sends a SAML assertion to Workday, and the user can get into Workday.
If you authenticate to Workday with a username and password prior to enabling SAML, a Workday cookie gets stored on the
browser. This cookie prevents SP­initiated SAML from working. To resolve this, simply clear any Workday cookies from your
browser.
Multiple IdP configurations
In Workday versions 21.0 and later, administrators can configure multiple IdPs.
Note:
To configure multiple IdPs, follow the steps found in the section called Configuring SAML in Workday on page 5.
When multiple IdPs are configured in Workday, SP­initiated SAML will not work. This is a Workday limitation. Deep links in Workday
Because Workday is Flash­based, not all links copied straight from the browser are considered deep links. Only true deep links will work
with the SAML configuration.
Note: Please check with your Workday support to clarify which links are supported as deep links. If you follow the network traffic of an SP­
initiated SAML flow using deep links, you will notice that the deep link will first trigger a redirect to https://<your_workday_tenant>/login­
saml2.flex. Then, a SAML request is sent to
the IdP.
Bypassing SAML after SAML is configured
Once SAML is enabled, users will not be able to sign in through their regular login page and must access Workday through Okta.
However, Workday provides a backup login URL that users can access to bypass SAML and sign in with their regular username and
password. That URL is [Your Workday URL]/login.flex?redirect=n. For example, if your Workday URL is
https://impl.workday.com/okta_pt1, you can bypass SAML by navigating to https://impl.workday.com/okta_pt1/login.flex?redirect=n.
Workday­Driven IT Provisioning Overview
top
Okta can import users and groups from Workday through its standard API. Okta supports two typical scenarios: 1) Import from Workday
and 2) Workday­driven IT provisioning.
Import from Workday
In the first configuration – Import from Workday, Okta simply imports users and groups from Workday like any other application. Imported
Workday users are used to create Okta users, and imported Workday groups can be used to assign apps. However, once the Workday
users are imported into Okta, they are no longer managed by Workday. Any updates to the user made in Workday will not change the
associated Okta user.
Workday­driven IT provisioning
In the second configuration – Workday­driven IT provisioning, Okta integrates with Workday to drive IT provisioning. When the
Workday user is imported into Okta, they continue to be managed by Workday. Updates and terminations made in Workday are reflected
in Okta and downstream apps. This arrangement enables Workday to manage employee and contractor access to apps. Workday­driven
IT provisioning is a superset of the functionality provided in Import from Workday, so the rest of this deployment guide focuses on
configuring Workday­driven IT provisioning, but will be relevant to Import from Workday scenarios as well.
Note: Workday­Driven IT provisioning requires the Enterprise or Enterprise Plus versions of Okta to enable Workday as a Profile
Master and for flexible attribute mappings.
With Workday­driven IT provisioning, Okta supports the following worker lifecycle events:
New hire
– A new Worker is hired in Workday
– Okta imports the new Worker and creates an Okta user profile
– Okta creates accounts in downstream apps (AD included)
Updates
– A Workday user’s attribute is changed in Workday
– Okta imports the attribute change
– Okta updates the attribute in downstream apps (AD included)
Termination
– A Worker is terminated in Workday
– Okta imports the status change
– Okta deactivates the Okta user and accounts in downstream apps (AD included)
Re­hire
– A terminated Worker is re­hired in Workday
– The de­activated Okta user needs to be manually reactivated in Okta
– Okta imports and re­links the re­hired Worker with the reactivated Okta user
Basic Provisioning Configuration
top
Creating an Integrator System User in Workday
Okta accesses the Workday APIs with a special type of Workday user known as an integration system user. To create one, type “create
integration system user” in the Search bar and select the resulting task. Follow the directions to create a username and password.
Granting permission to an integration system user
Now you need to grant this integration system user permission to access the Web services needed for the Okta­Workday integration
through Workday Security Groups.
1. To create a new Security Group, type “create security group” in the Search bar.
2. Click on the Create Security Group search result.
3. In the Type of Tenanted Security Group drop­down menu, select Integration System Security Group (Unconstrained), as
shown below.
Figure 4: Creating an Integration System Security group.
1. Create a name for the group.
2. On the next screen, under Integration System Users, add your integration system user to the list. To come back to this group
for future edits, simply type in the security group name in the Search bar.
3. Ensure that the group you created has proper access to a set of business domains (listed below) needed for Okta integration.
Repeat steps a–e (below) for these domains:
“External Account Provisioning” – Get and Put
“Worker Data: Public Worker Reports” – Get and Put
“Worker Data: Work Contact Information” – Get and Put
“Worker Data: Current Staffing Information” – Get
“Worker Data: All Positions” – Get
“Worker Data: Business Title on Worker Profile” – Get
A. Type “Domain Security Configuration” in the Search bar.
B. Select the resulting report.
C. In the new search field, type the domain name in the Domain field. Click the OK button.
Figure 5: Viewing the External Account Provisioning domain.
D. On the subsequent page, click the ellipsis after the domain name to reveal a drop­down menu. Select Domain > Edit
Security Policy Permissions.
Figure 6: Editing the Security Policy Permissions.
E. Add the security group you created earlier to the appropriate section under Integrated Permissions based on the above
domain list
(e.g., Get and Put vs Get).
Figure 7: Adding the Group to the domain.
7. WD might alert you to activate the security policy changes.
If you do not activate, the integration user account will not have the necessary permissions.
To activate, do the following:
a. Type “Activate Pending Security Policy Changes” in the Search bar..
b. Select the resulting task.
c. Enter a comment (required) and click the OK button to activate.
Configuring Provisioning in Okta
To set up the API integration, go to the Okta Provisioning tab in your Workday instance.
Figure 8: Setting up the API integration.
The API username format will be <integration system user name>@<tenant>. For example, wd_integration@oktademo. The tenant name
can be found in your Workday URL. To obtain the Web services endpoint, it’s easiest to look up the WSDL of any of the Web services in
your org:
1. Type “public web services” in the Search bar.
2. Under Reports, select Public Web Services.
3. From the Public Web Services list, select any one of them and click the ellipsis to reveal a drop­down menu. Select Web
Service > View WSDL, which displays the full WSDL in a separate window.
Figure 9: Viewing the WSDL.
4. In the WSDL, search for soapbind:address to see the Web services endpoint corresponding to the Web service that you chose.
5. For the Okta configuration, you only need the URL up to the tenant name. For example, if the value in the WSDL is
https://implcc.workday.com/ccx/service/okta_pt1/Human_Resources/v19, you only need to put https://impl­
cc.workday.com/ccx/service/okta_pt1.
The Pre­Start Interval determines how many days before the hire­date you should have the user imported and activated
in Okta. For more information, see Pre­Start interval details.
The Department Field determines which worker attribute is used for the department attribute of the user in Okta. By
default, the value is “Business Unit”.
Sync Personal Phones allows Okta to use personal phone numbers accessed from Workday if work phone numbers are
otherwise unavailable.
Only Import Workers with Workday allows you to import only Workday workers who have Workday accounts and
automatically filter out workers who don't. By clicking this button, your next import will only include valid Workday
workers.
Provisioning features
Scheduled imports
For the Workday­driven IT provisioning scenario, Okta recommends setting up scheduled import and automatic confirmation so that
worker life cycle events in Workday are periodically propagated to Okta without the need for manual intervention. Note that imports can
take time to complete if there are a large number of Workers in Workday, so it’s not advisable to schedule imports too frequently.
Figure 10: Setting up scheduled import and automatic confirmation.
Workday as Profile Master
Workday as a Profile Master should also be enabled in the Workday­driven IT provisioning scenario so that Workday manages the Okta
users. Furthermore, Workday should be listed as the highest priority Profile Master, specifically above the Active Directory (AD) instance to
which it will create users.
Figure 11: Profile Mastery in Okta.
Pre­Start interval details
The Pre­Start Interval is an optional field for early provisioning of Workday users. It allows you to on­board a user account into Okta prior
to the official Worker/Employee Date(this is the employee’s actual start date). The interval represents the number of days prior to a
Workday user’s stated Worker/Employee Date that Okta will evaluate a Workday user for early import. If the feature is enabled, Okta
evaluates the Workday Pre­Hire Date; then if it falls within the set interval, Okta imports the user.
For example, if you set the Pre­Start Interval in Okta to 7 days, and a given Workday account has its Pre­Hire Date configured to 7 days
prior to their Worker/Employee Date, Okta imports the account. In this same scenario, if the Pre­Hire Date is greater than the 7­day
interval configured in Okta, Okta does not consider it for import until the beginning of the window defined by the Pre­Start Interval.
Keep in mind that:
You must have Profile Mastering enabled to use the Pre­Start Interval option.
A best practice is to configure the interval to encompass the largest amount of time likely to be required before the Pre­Hire Date
(i.e., the greatest amount of time needed for
on­boarding).
The interval doesn’t define when a user will be imported; it specifies when they’re eligible to be imported if they have a Pre­Hire
Date.
Workday Provisioning Groups
top
Workday Provisioning Groups can be used to import workers into Okta in an organized way. Like Active Directory Security Groups,
imported Workday Provisioning Groups can be seen under the People > Group tab. These groups can be used like any other Okta group
—for app assignments, multi­factor authentication (MFA) policy assignments, etc. The groups can also be used to drive provisioning into
Active Directory and other applications. Provisioning groups must be created manually inside Workday. Once created, the groups and
associated memberships become part of the import into Okta.
Granting Provisioning Group Admin Privileges to a Workday Administrator
Before a Workday admin can manage Provisioning Groups, you must ensure they have the correct privileges. If you have typed
“provisioning groups” in the search bar and do not see the options to Create Provisioning Groups, Delete Provisioning Groups,or Edit
Provisioning Groups, this indicates that the admin does not have the required privileges.
To add Provisioning Group access:
1. Type “domain security” in the Search bar and select Domain Security Policies for Functional Area.
2. Type “System” and click the OK button.
3. On the next screen, in the left pane, scroll down and expand the Security Administration folder. Then click Provisioning
Group Administration.
4. Next to Provisioning Group Administration in the right pane, click the ellipsis to reveal a drop­down menu and select Domain
Security Policy. If the second item says Enable, it means the policy is currently disabled. To enable it, click Enable. There will
be a confirmation box following the selection. If the second item says Disable, it means the policy is currently enabled. Move to
the next step.
Figure 12: Enabling Domain Security Policy, if disabled.
1. Under the Report/Task Permissions list, ensure that the admin is a member of one of the Security Groups with view and
modify permissions. If not, click the drop­down menu next to Domain Security Policy and select Domain Security Policy >
Edit Permissions to add the right Security Group to the list. Be sure to add it to the list with both view and modify
permissions.
Assigning Workday Workers to Provisioning Groups
Workday workers can be manually assigned to provisioning groups within Workday; however, provisioning groups are most effective when
configured to have automated assignments based on conditional rules—defined in a business process within Workday. Because it
involves modifying a business process inside Workday, a Workday HR administrator would probably perform this step.
Provisioning Users to Active Directory via Provisioning Groups
Okta can automate the creation, update, and deactivation of users from Workday to Active Directory (AD). Okta drives provisioning via
Workday provisioning groups. In short, a Workday provisioning group is tied to one (or more) AD organization unit (OU) within Okta. When
a user is created in Workday and assigned to a properly configured provisioning group, Okta imports that user from Workday and creates
a user in AD under the corresponding OU.
To provision users to AD via provisioning groups:
1. Log into Okta.
2. Find the desired Workday provisioning group under People > Groups.
3. Click on the group.
4. Click the Manage Directories button.
5. Select an AD domain(s) to associate with the Workday provisioning group.
6. Select the AD OU within which you wish to provision accounts.
7. Click the Done button.
8. In the Okta AD Settings tab, enable Provision new Active Directory accounts from Okta.
Changing Provisioning Groups
If an existing Worker is added to a different provisioning group in Workday, this will result in a membership change in the associated group
in Okta. However, the OU location of the associated AD user does not change. This is because Okta only adds AD users to a particular
OU during AD user creation—updates do not apply.
Using Real Time Sync
top
The Real­time sync (RTS) feature updates user profiles, groups, and group memberships during sign­in instead of waiting for a scheduled
import. You do not have to import all the users in your directory beforehand. Real­time sync also updates user information whenever you
load or refresh a user's People page.
For details on setting up and using RTS in Workday, see the Workday Real­Time Sync Setup Guide.
Attribute Mappings and Active Directory
top
Attribute Mappings from Workday to an Okta User Profile
As shown in the Universal Directory (UD) Profile Editor, the base profile that Okta imports from Workday consists of 20 attributes. Some of
these attributes are mapped to the Okta user profile by default, and others must be created for the Okta user first as custom attributes,
then mapped manually. Figure 14 shows the recommended mappings from a Workday to Okta user for typical use cases, which includes
all attributes in the Workday base profile except for Worker Type, Manager ID, and Manager Username.
Note: When Workday is configured to write to AD (and UD is enabled), the Okta admin must manually map some attributes between the
Workday app user profile and the Okta user profile. Additionally, the admin must manually map some attributes between the Okta user
profile and the AD user profile. This allows attributes to flow from Workday to Okta and then
to AD.
Figure 16: Suggested mappings from Workday to Okta user.
Attribute Mappings to AD User Profile
Workday as a Master typically involves creating AD users. Some of the attribute mappings from Okta user to AD user exist by default, but
others need to be created manually. Figure 15 shows the recommended mappings for typical use cases.
Figure 17: Suggested mappings from an Okta to Active Directory user.
Custom Expressions
UD supports the use of custom expressions in profile mappings to transform attributes. As shown in Figure 17, custom expressions are
used to populate the SAM Account Name and Manager (UPN).
The Manager (UPN) attribute is important for linking managers in AD. The full custom expression for Manager (UPN) is as follows:
hasWorkdayUser()?(findWorkdayUser().managerUserName + "@" + target_app.namingContext):null
In plain­English, the custom expression is doing the following: If Workday profile exists for this Okta user, then find the
managerUserName attribute of the Workday profile was imported into Okta and append @[AD domain] to populate the Manager (UPN)
attribute.
Okta uses the Manager (UPN) attribute to find the Active Directory user in AD that is this Okta user’s manager, and links the two AD users
together. This custom expression can be modified to construct the Manager (UPN) attribute differently to suit special AD environments.
Two other situations can result in additional custom expressions appearing in the Provision to AD profile mappings. The first is when UD is
turned on for a pre­existing Workday as a Master deployment. The second is when the Workday integration is added to Okta first, before
AD is added. In both cases, the Workday attributes of Business Title, Location, Supervisory Organization, Business Unit, and Employee ID
are mapped directly to their corresponding AD attributes directly via custom expression. This works perfectly well.
Workday Custom Attributes
Okta's Workday application has been enhanced to support UD, enabling Okta to import more than 20 attributes from Workday. To support
this, Okta can import attributes from a separate Workday web services endpoint—a reports­as­a­service endpoint. In short, a customer
creates a custom report in Workday and adds attributes to it. Workday exposes a web services endpoint for that custom report, and Okta
imports the additional attributes. UD maps the incoming attributes to the Okta user profile and to downstream app user profiles.
Creating a custom report in Workday
Signing into Workday
1. Search for create custom report, and select the resulting task.
2. Complete the subsequent fields:
1. Create a report name in the Report Name field.
2. Choose Advanced as the Report Type; this displays in the Web Service Enable checkbox.
3. Check the Web Service Enable checkbox.
4. Click the OK button.
Figure 18: Creating a custom report.
1. Add desired attributes to the custom report.
2. If you wish to change the imported attribute’s name, modify the Column Heading Override XML Alias column.
1. Add the Workday ID attribute to the custom report.
1. Change the Column Heading Override XML Alias to Workday_ID.
2. Without Workday_ID, Okta will not successfully import custom attributes.
Figure 19: Adding a Workday_ID to the custom report.
1. After creating the new custom report, click on the ellipsis after the report name and go to Web Service > View Urls.
2. Get the following URLs by right­clicking on the link and selecting "Copy URL":
1. XSD (under Simple XML heading)
2. JSON (under JSON heading)
3. Share the custom report with your integration user:
1. Search for “Edit Custom Report”.
2. Find your custom report.
3. Select the Share Tab > Share with specific authorized groups and users.
4. Select your integration user.
Creating a Paginated Workday Custom Report (Not necessary if the Org is < 5000 users)
When there are more than 5000 users, imports from Workday that involve custom reports can sometimes timeout. The solution is to create
a paginated custom report, which allows Okta to import chunks of Worker data without timing out. To use this option, do the following:
1. Under the Filter tab, set up your filter as shown below.
2. Under the Prompts tab, specify the prompt default values as shown below.
3. Find the Workday ID for all admins in Workday.
4. View the generated URLs by clicking Actions > Web Service > View URLs, as shown below.
5. In the Employee_ID_Prompt field enter the admin's Workday ID.
Note: Do not de­provision or remove an active admin. If this happens, you'll need to regenerate the URLs by entering a new admin's
Workday ID.
6. Obtain the newly paginated URLs by right­clicking on the link and selecting "Copy URL":
XSD (under the Simple XML heading)
JSON (under the JSON heading)
7. Generate the reports as before, adding the new URLs.
Known Issues
Okta does not display Arabic characters imported from Workday correctly. Removing a custom attribute in Workday, and then importing into Okta does not erase the custom attribute value that was
previously imported.
Signing Into Okta
1. Navigate to the Workday App.
2. Navigate to the Provisioning tab.
3. Paste the URL from step 6a above into Custom Report Simple XML XSD URL (optional). Okta uses the XSD URL to get the
custom report’s schema.
4. Paste the URL from step 6b above into Custom Report JSON URL (optional). Okta uses the JSON URL to get the custom
report's data.
Okta can now import any attribute from Workday via the custom report web services endpoint. Final steps includeExtending the Workday
app user profile, the Okta app user profile, and optionally the AD user profile with new attributes.
Mapping attributes between profiles and apply transformations, if required.
For detailed instructions, please refer to the About Universal Directory.
File
Attachment
File
Attachment 2
Announcement https://support.okta.com/help/oktaSupportRedirect?RelayState=%2Fhelp/articles/Knowledge_Article/96431486­Workday­Deployment­
­ Customer
URL Guide­Version­4­0
Public URL ­
Okta
https://support.okta.com/help/articles/Knowledge_Article/96431486­Workday­Deployment­Guide­Version­4­0
Documentation
only
Internal OKTA
https://na10.salesforce.com/ka0F0000000UDJb
link