---
category: [Administration & Integrations, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions, Platform and Product Extensions/Integration]
keyword: [Integrate, Workday Integration, Orchestrate for Integrations]
nav: wcp_docs
parent_url: /wcp_docs/
title: >- 
  Concept: Integration App Security
layout: subsection
---

When designing your integration app, it's critical that you consider security configurations to protect access to your app and data. You can configure security at these levels:

-   Domain security policies for Workday services.
-   Authentication credentials for orchestrations.
-   Endpoint authentication.


Consider the security provided at broader levels that encompass data access and visibility at the widget level. This approach can reduce scattered security checks and simplify your app development.

## <a id="section_ubd_znm_4qb"></a>Service Domain Security Policies

An app that invokes Workday services inherits the Workday configurable security model, which provides the core security of your integration app. Workday services include the Workday REST APIs, Workday SOAP APIs, Workday Query Language, and custom reports invoked as Reports-as-a-Service endpoints.

The domain security policies control who can read and write Workday data through your app. As such, configuring domain security policies is a fundamental task. For each Workday service invoked by your app, you or the Workday administrator must correctly configure the appropriate domain security policies. The endpoint descriptions in the Workday REST API documentation display the security domains required by the data accessed by the API.

When you edit the security policy permissions for the domain that secures the REST API, add a <b>Report/Task</b> permission for the security groups. Select the proper permission for each security group:

-   <b>View</b> for the GET method.
-   <b>Modify</b> for the POST, PUT, PATCH, DELETE methods.


Domain security policies grant access to security groups, which can be:

-   User-based.
-   Role-based.
-   Job-based.
-   Integration groups.
-   Other context-sensitive groups.


Based on the security groups of users and their configured security policies, the Workday services:

-   Return only the data that the user has permission to read.
-   Create, update, or delete only the data that the user has permission to write.
-   Return permission errors if the user doesn't have access to an object.


Collaborate with your Workday functional experts who understand the business roles, security groups, and the functional configurations in your tenant. Instead of hard-coding security checks in your app, you can leverage existing tenant security configurations that can help drive the app functionality.

Here are some examples of how service-level security can help with your app design:

-   Invoke custom reports (through Reports-as-a-Service) that retrieve restricted data based on user roles. Example: To enable supervisors to get worker data only within the organization they supervise, a custom report can use the <i>Workers By Role</i> data source filter. On a calculated field, you can use a role prompt that limits the results based on the user role.
-   Intercept a permission error or a 403 HTTP status code from a Reports-as-a-Service endpoint and display a user-friendly custom error page.


For details about Workday configurable security, see the [Configurable Security](https://doc.workday.com/r/Z9lz_01hqDMDg6NSf7wCBQ/xFmzY3c9jjm79W~CBq0jCw) section in the Workday Administrator Guide.

## <a id="section_xlx_xjn_4qb"></a>Orchestration Authentication

You can select the type of authentication credentials for sending API requests from orchestrations in your app:

-   API Key - Requires a key-value pair containing an API key as a query parameter or header value.
-   Basic Authentication - Requires a username and password.
-   OAuth - Requires a token or cred store reference.
-   Integration System User - Requires an ISU username. The ISU credential uses the simplified ISU authentication.


For details about creating credentials for orchestrations, see [Create Orchestration Credentials](/wcp_docs/GUID-d93db6e9-f07a-4e89-9ad0-2070f54c3286.html).

## <a id="section_lt3_2pt_4qb"></a>Endpoint Authentication

You can specify an authentication scheme for each endpoint invoked by an integration app. The default endpoint authentication scheme for integration system orchestrations is <i>Access Token From Initiating User</i>, which uses the same credentials as the user that launches the Integration. This authentication scheme can be applied to Workday REST APIs, Workday SOAP APIs, and Prism APIs. The <i>Integration System User</i> endpoint authentication scheme is also available for Business Process Template orchestrations.

<b>Note:</b> The ISU authentication scheme is always a security exception. Where possible, configure an ISU on the Integration System launching the integration system orchestration or in the Orchestrate Service Step configuration of the Business Process launching the Business Process orchestration.

The ISU authentication scheme uses ISU access to enable end users to read and write data. Because the ISU access doesn’t typically align with tenant configurations for end users, you must consider additional security checks in your app.

However, if your app needs to use ISU authentication, you’ll need to code business logic to check the roles and security groups of the current user. This check typically includes additional API calls to run a custom report about the user security details, which can affect performance.

If your app invokes external endpoints, specify the appropriate authentication scheme for each endpoint. Example: OAuth2.