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

When designing your 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.
-   Domain security policies for model components.
-   Authentication credentials for orchestrations.
-   Page level security.
-   Endpoint authentication.
-   Presentation component visibility.


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 app. Workday services include the Workday REST APIs, Workday Graph API, 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 a few 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.
-   Create different pages based on unconstrained and constrained user roles.


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_w2k_gjn_4qb"></a>Security Domains as Model Components

When you create business objects and business processes in your app, you can create security domains that protect access to your custom data and business processes. These security domains extend the Workday configurable security model, which enables you to use the same security groups in the tenant.

For details about creating security domains as model components of your app, see [Add Security Domains](/wcp_docs/azx1677268395516.html).

When you create a business process in your app, consider the security in context with the routing requirements of the business process. You can route a business process to constrained security groups. See [Reference: Design Considerations for Business Processes](/wcp_docs/tms1613766987100.html).

## <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. Examples:

-   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/uwh1613475703138.html).

## <a id="section_zqd_x3n_4qb"></a>Page Security

To control access to the pages in your app, use the security domains of your app. Only users whose security group has permission on the assigned security domain can access the page.

By default, any user in the tenant can access all pages in a custom app. If a page requires security, Workday recommends that you secure access to the page by using the security domains in your app.

<b>Note:</b> If you've assigned a security domain to a custom task that opens a page, that security domain doesn't apply to the other pages in the app.

<b>Note:</b> Because Workday doesn't apply contextual security to the pages of an app, we recommend that you use only unconstrained role-based security groups for page security. Constrained security on the pages of an app is derived from the endpoint authentication scheme.

For details about enforcing page-level security, see [Steps: Secure the Pages of an Extend App](/wcp_docs/sfv1677268046417.html).

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

You can specify an authentication scheme for each endpoint invoked by a page. The default endpoint authentication scheme on a page is Workday Single Sign-On (SSO). This authentication scheme applies to Workday REST APIs and Graph API. These Workday APIs authenticate the signed-in user using the security configuration on the tenant. The SSO authentication scheme automatically provides the service-level security in your app.

The Integration System User (ISU) authentication scheme is also available with Workday REST APIs and Graph API. However, you must take caution and add security checks in your app when using ISU authentication.

<b>Note:</b> The ISU authentication scheme is always a security exception.

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 the tenant configurations for end users, you must consider additional security checks in your app. In general, we recommend using the security domains in your app to secure a page. 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 page performance. See [Concept: ISU Authentication](/wcp_docs/GUID-cb3e0fcd-bb97-4005-8d10-3a02e88dab71-enHYPHENus.html).

If the pages in your app invoke external endpoints, specify the appropriate authentication scheme for each endpoint. Examples: OAuth2 Authorization Code, OAuth2 Client Credentials, and Amazon Web Services Signature.

See [Declare Authentication Types in the SMD](/wcp_docs/nyw1530545468565.html) and [Define Endpoint Authentication in the PMD](/wcp_docs/yea1530546235609.html).

## <a id="section_m1z_cjn_4qb"></a>Presentation Components

To protect the data displayed or entered on a page, ensure that you've considered the security mechanisms provided at the service and page levels. After you've applied these security mechanisms, your app might still need to apply business rules based on worker role, position type, and others. In these cases, you can apply business rules or security to set these attributes conditionally:

-   `visible` - Displays or hides the widget.
-   `render` - Renders or excludes the widget from the page load.
-   `enabled` - Enables or disables the edit mode of the widget.


You can use a model business object with security domains for field-level security. See [Control Widgets with Model Component Security](/wcp_docs/GUID-5324da2c-510d-4c3e-9645-95b0e5d7a084-enHYPHENus.html).

For details about these attributes for each PMD tag, see [Reference: PMD Tags](/wcp_docs/dyg1528862158582.html).