13.2 Integration Security: ISUs, ISSGs & Web Services

13.2 Integration Security: ISUs, ISSGs & Web Services

Quick Answer: All Workday integrations must execute under non-human service accounts known as Integration System Users (ISUs). To protect the tenant, ISUs must be flagged with Do Not Allow Direct Login, preventing interactive browser-based sessions. Permissions are granted by placing the ISU into an Integration System Security Group (ISSG), which is then assigned Get (read) or Put (write) permissions on the necessary Domain Security Policies. Changes take effect only after running Activate Pending Security Policy Changes. External systems authenticate using X.509 digital certificates or OAuth 2.0 Client Credentials. When exposing custom reports via Report-as-a-Service (RaaS), data visibility is strictly bounded by the invoking ISU's security context.

---

Integration System Users (ISU): Non-Human Service Identities

In an enterprise production environment, running an automated integration under an employee's personal user account creates severe operational, security, and compliance risks. If the employee changes roles, takes a leave of absence, or terminates employment, their account is locked or reassigned, causing mission-critical interfaces to fail immediately. Furthermore, human accounts often possess broad, unneeded permissions across multiple functional domains, violating the principle of least privilege.

The Role of the Integration System User (ISU)

An Integration System User (ISU) is a specialized, non-human service account created via the Create Integration System User task. ISUs exist exclusively to execute scheduled integrations, process API requests, and establish web service connections.

+---------------------------------------------------------------------------------------+
|                         CREATE INTEGRATION SYSTEM USER                                |
+---------------------------------------------------------------------------------------+
|  User Name:                  ISU_Payroll_Outbound_ADP                                 |
|  Password / Confirm:         [ Encrypted / Managed Key ]                              |
|  [X] Do Not Allow Direct Login   <-- CRITICAL EXAM WATCHPOINT (Blocks Web UI Access)   |
|  Session Timeout Minutes:    30                                                       |
|  Password Never Expires:     [ Configurable per corporate security policy ]           |
+---------------------------------------------------------------------------------------+

Critical ISU Configuration Attributes

1. Do Not Allow Direct Login (Mandatory Audit Rule): This checkbox is a fundamental security safeguard. Enabling it blocks the ISU from logging into the Workday graphical user interface (UI) through a web browser. The account can only authenticate via web service APIs, EIB launches, and Studio endpoints. This prevents malicious actors from hijacking service account credentials to access interactive screens.
2. Exemption from Multi-Factor Authentication (MFA): Automated background scripts and external middleware (e.g., MuleSoft, Boomi) cannot respond to interactive MFA prompts. ISUs are exempted from browser-based MFA policies, necessitating robust alternative controls such as certificate authentication, OAuth 2.0, or strict IP whitelisting.
3. Session Timeout Tuning: Integration processes often transfer extensive datasets requiring sustained execution times. Administrators tune the session timeout setting on the ISU to accommodate long-running batch jobs without premature termination.
4. Enterprise Naming Standards: Certified administrators enforce clear naming conventions reflecting purpose, direction, and target system: ISU_<Direction>_<TargetSystem>_<Function> (e.g., ISU_Outbound_ADP_Payroll, ISU_Inbound_Cornerstone_LMS).

---

Integration System Security Groups (ISSG) & Domain Policy Assignment

In Workday's security model, users do not receive permissions directly. An ISU has zero access upon creation. To grant access, the administrator assigns the ISU to an Integration System Security Group (ISSG).

+-----------------------+       Member Of       +-------------------------------------+
|      INTEGRATION      | --------------------> |      INTEGRATION SYSTEM             |
|   SYSTEM USER (ISU)   |                       |     SECURITY GROUP (ISSG)           |
+-----------------------+                       +-------------------------------------+
                                                                   |
                                                                   | Assigned To
                                                                   v
                                                +-------------------------------------+
                                                |    DOMAIN SECURITY POLICIES         |
                                                |    - Worker Data: Public Worker     |
                                                |    - Worker Data: Current Staffing  |
                                                |    - Worker Data: Base Pay          |
                                                +-------------------------------------+
                                                                   |
                                        +--------------------------+--------------------------+
                                        |                                                     |
                                        v (Read Operations)                                   v (Write Operations)
                        +-------------------------------+                     +-------------------------------+
                        |        GET PERMISSIONS        |                     |        PUT PERMISSIONS        |
                        | - View fields in RaaS reports |                     | - Inbound EIB data load       |
                        | - Extract data via SOAP/WWS   |                     | - Execute web service updates |
                        +-------------------------------+                     +-------------------------------+

Creating and Populating the ISSG

1. Execute the Create Security Group task.
2. Select the type: Integration System Security Group (Unconstrained) or Integration System Security Group (Constrained).
   • Unconstrained ISSG: Grants access across all organizations and populations in the tenant. Typical for enterprise-wide outbound feeds (e.g., corporate payroll or 401(k) benefit files).
   • Constrained ISSG: Restricts the integration's visibility to specific organizations, locations, or companies. Used when an integration should only access records within a specific subsidiary or region.
3. Add the target ISU to the security group's membership list.

Domain Security Policies: Get vs. Put Permissions

Every functional attribute and web service operation in Workday is governed by a Domain Security Policy residing within a specific Functional Area. The administrator must explicitly configure access rules:

• Get Access: Grants read-only authority. Required for outbound integrations, custom report queries (RaaS), and data extraction web services.
• Put Access: Grants write, update, and creation authority. Required for inbound integrations loading external records, modifying worker data, or executing business process web service transactions.

The Mandatory Activation Step (Activate Pending Security Policy Changes)

Modifying a domain security policy places the tenant into a pending security state. Changes do NOT take effect immediately.

Exam Trap: A common exam scenario describes an administrator creating an ISU, configuring an ISSG, and granting Get access to the Worker Data: Personal Info domain. However, when the integration executes, it fails with an HTTP 403 Forbidden or authorization error. The missing step is executing the Activate Pending Security Policy Changes task and confirming the changes with an electronic signature comment.

---

Authentication Protocols: Certificates & OAuth 2.0

Securing integration transport involves transitioning away from legacy basic authentication toward modern cryptographic standards.

1. Basic Authentication (Legacy)

Basic authentication transmits the ISU username and password within the HTTP authorization header (base64 encoded) over TLS/SSL. While supported, enterprise governance policies strongly discourage basic authentication due to credential leakage risks and password rotation maintenance.

2. X.509 Digital Public Key Certificates

Workday supports certificate-based authentication for web services:

• The administrator or integration developer generates an RSA public/private key pair.
• The X.509 Public Key Certificate is uploaded directly to the ISU record in Workday via the Maintain Integration System User related actions menu.
• The client application signs outgoing SOAP requests or presents the client certificate during mutual TLS (mTLS) handshakes. Workday validates the signature against the registered certificate, authenticating the request without transmitting passwords.

3. OAuth 2.0 Framework

For modern REST APIs and enterprise API gateways (e.g., Apigee, MuleSoft), Workday supports OAuth 2.0 utilizing the Client Credentials Grant flow:

• API Client Registration: Administrators execute the Register API Client task, defining client name, client type (Non-Public), and assigned scopes.
• Token Generation: The external system requests a short-lived Bearer token from the Workday OAuth token endpoint (/oauth2/token) using its client_id and client_secret.
• API Invocations: Subsequent REST or WQL requests supply the Bearer token in the Authorization: Bearer <token> header, ensuring high-security, time-bounded access.

---

Report-as-a-Service (RaaS): Turning Reports into APIs

Report-as-a-Service (RaaS) is one of the most widely deployed integration patterns in the Workday ecosystem. It allows administrators to build an Advanced Report using the graphical Report Writer and expose it instantaneously as a secure web service endpoint.

+---------------------------------------------------------------------------------------+
|                               RAAS CONFIGURATION STEPS                                |
+---------------------------------------------------------------------------------------+
|  1. CREATE ADVANCED REPORT   | Build report with required fields and calculated fields|
|  2. ENABLE AS WEB SERVICE    | Flag 'Enable as Web Service' on the Advanced tab       |
|  3. WEB SERVICE ALIASES      | Assign clean XML element names to each column          |
|  4. COPY REST/WSDL URL       | Retrieve endpoint URL from Report > Web Services menu  |
|  5. ASSIGN ISU SECURITY      | Ensure invoking ISU has 'Get' access to all domains     |
+---------------------------------------------------------------------------------------+

RaaS Endpoint Formats

RaaS automatically renders report data in multiple output formats based on the requested endpoint URL:

• Workday XML (/wd:Report_Data): Standard hierarchical XML preserving Workday schema structures and sub-element collections.
• Simple XML: Stripped XML format eliminating internal namespace wrappers, optimized for legacy middleware parsers.
• JSON (format=json): Clean JavaScript Object Notation, ideal for modern web portals, cloud microservices, and mobile applications.
• CSV (format=csv): Delimited plain text for direct consumption by spreadsheets or flat-file ETL pipelines.

Security Evaluation in RaaS: The "Silent Omission" Phenomenon

When an external system invokes a RaaS endpoint, Workday evaluates the security context of the authenticating user (the ISU) in real time:

• Field-Level Security Suppression: If the report definition includes 15 columns, but the ISU belongs to an ISSG that lacks Get permissions on the Worker Compensation domain, the report does not fail. Instead, it executes successfully, but the compensation columns return completely empty/null!
• Exam Watchpoint: If an integration developer reports that an outbound RaaS integration runs without errors but output files are missing salary numbers, the issue is security domain authorization, not a broken report filter or failed calculation.

---

Integration Security Governance Matrix

The following table contrasts human user security with integration security architecture:

---

Certification Pitfalls & Common Exam Traps

1. The "Do Not Allow Direct Login" Misconception: Exam questions often test whether checking "Do Not Allow Direct Login" prevents an ISU from executing integrations. Candidates must remember: it only blocks interactive browser UI logins. It has zero negative impact on API, SOAP, REST, or EIB executions.
2. The Missing Security Activation Trap: When configuring integration security, adding domains to an ISSG does not take effect until an administrator runs Activate Pending Security Policy Changes. Questions describing an integration that fails with authorization errors immediately after security assignment are testing this exact requirement.
3. Silent Data Omission in RaaS: When an ISU lacks permissions for a field exposed in a RaaS report, the web service call does not throw an HTTP error or crash. Workday returns an HTTP 200 OK status code with an XML/JSON payload where the unauthorized fields are silently omitted or empty.
4. Constrained vs. Unconstrained ISSG for Global Integrations: If an outbound benefits integration must extract all global employees, placing the ISU in a Constrained ISSG tied to the US Subsidiary will result in non-US workers being omitted from the file. Global feeds require an Unconstrained ISSG.