Workday Deployment Guide Version 4.0

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 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. top

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 SPinitiated SAML flow using deep links, you will notice that the deep link will first trigger a redirect to https://<your_workday_tenant>/loginsaml2.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 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 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. top top

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://implcc.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

Provisioning features Scheduled imports 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. 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 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. top 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 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 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. top top

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 Customer URL https://support.okta.com/help/oktasupportredirect?relaystate=%2fhelp/articles/knowledge_article/96431486 Workday Deployment Guide Version 4 0 Public URL Okta Documentation only https://support.okta.com/help/articles/knowledge_article/96431486 Workday Deployment Guide Version 4 0 Internal OKTA link https://na10.salesforce.com/ka0f0000000udjb