diff --git a/src/content/docs/cloudflare-one/applications/non-http/browser-rendering.mdx b/src/content/docs/cloudflare-one/applications/non-http/browser-rendering.mdx index 1179e407043f3f..711c500ad2de66 100644 --- a/src/content/docs/cloudflare-one/applications/non-http/browser-rendering.mdx +++ b/src/content/docs/cloudflare-one/applications/non-http/browser-rendering.mdx @@ -19,8 +19,8 @@ To enable browser rendering: 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. 2. Locate the SSH or VNC application you created when [connecting the server to Cloudflare](/cloudflare-one/connections/connect-networks/use-cases/ssh/). Select **Configure**. 3. In the **Policies** tab, ensure that only **Allow** or **Block** policies are present. **Bypass** and **Service Auth** are not supported for browser-rendered applications. -4. In the **Settings** tab, scroll down to **Additional settings**. -5. For **Browser rendering**, choose *SSH* or *VNC*. +4. Go to **Advanced settings** > **Browser rendering settings**. +5. For **Browser rendering**, choose _SSH_ or _VNC_. 6. Select **Save application**. When users authenticate and visit the URL of the application, Cloudflare will render a terminal in their browser. diff --git a/src/content/docs/cloudflare-one/applications/non-http/cloudflared-authentication/automatic-cloudflared-authentication.mdx b/src/content/docs/cloudflare-one/applications/non-http/cloudflared-authentication/automatic-cloudflared-authentication.mdx index bd7941f02be4b8..219b288bb671db 100644 --- a/src/content/docs/cloudflare-one/applications/non-http/cloudflared-authentication/automatic-cloudflared-authentication.mdx +++ b/src/content/docs/cloudflare-one/applications/non-http/cloudflared-authentication/automatic-cloudflared-authentication.mdx @@ -16,7 +16,7 @@ To enable automatic `cloudflared` authentication: 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. 2. Locate your application and select **Configure**. -3. In the **Settings** tab, scroll down to **Additional settings**. +3. Go to **Advanced settings** > **Browser rendering settings**. 4. Turn on **Enable automatic cloudflared authentication**. 5. Select **Save application**. diff --git a/src/content/docs/cloudflare-one/identity/authorization-cookie/cors.mdx b/src/content/docs/cloudflare-one/identity/authorization-cookie/cors.mdx index ef3da21b79b745..73012724cd54e6 100644 --- a/src/content/docs/cloudflare-one/identity/authorization-cookie/cors.mdx +++ b/src/content/docs/cloudflare-one/identity/authorization-cookie/cors.mdx @@ -51,8 +51,8 @@ There are three ways you can resolve this error: You can configure Cloudflare to send OPTIONS requests directly to your origin server. To bypass Access for OPTIONS requests: 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Locate the origin that will be receiving OPTIONS requests and select **Edit**. -3. In the **Settings** tab, scroll down to **CORS settings**. +2. Locate the origin that will be receiving OPTIONS requests and select **Configure**. +3. Go to **Advanced settings** > **Cross-Origin Resource Sharing (CORS) settings**. 4. Turn on **Bypass options requests to origin**. This will remove all existing CORS settings for this application. It is still important to enforce CORS for the Access JWT -- this option should only be used if you have CORS enforcement established in your origin server. @@ -65,11 +65,11 @@ To configure how Cloudflare responds to preflight requests: 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Locate the origin that will be receiving OPTIONS requests and select **Edit**. +2. Locate the origin that will be receiving OPTIONS requests and select **Configure**. -3. In the **Settings** tab, scroll down to **CORS settings**. +3. Go to **Advanced settings** > **Cross-Origin Resource Sharing (CORS) settings**. -4. Configure the dashboard [CORS settings](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#the_http_response_headers) to match the response headers sent by your origin. +4. Configure these [CORS settings](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#the_http_response_headers) to match the response headers sent by your origin. For example, if you have configured `api.mysite.com`to return the following headers: diff --git a/src/content/docs/cloudflare-one/identity/authorization-cookie/validating-json.mdx b/src/content/docs/cloudflare-one/identity/authorization-cookie/validating-json.mdx index 250346f1b032fd..d3a995afc72141 100644 --- a/src/content/docs/cloudflare-one/identity/authorization-cookie/validating-json.mdx +++ b/src/content/docs/cloudflare-one/identity/authorization-cookie/validating-json.mdx @@ -67,7 +67,7 @@ As shown in the example below, `https://.cloudflareaccess.com/cd * Validate tokens using the external endpoint rather than saving the public key as a hard-coded value. -* Do not fetch the current key from `public_cert`, since your origin may inadvertently read an expired value from an outdated cache. Instead, match the `kid` value in the JWT to the corresponding certificate in `public_certs`. +* Do not fetch the current key from `public_cert`, since your origin may inadvertently read an expired value from an outdated cache. Instead, match the `kid` value in the JWT to the corresponding certificate in `public_certs`. ::: ## Verify the JWT manually @@ -100,7 +100,7 @@ To get the AUD tag: 1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. 2. Select **Configure** for your application. -3. On the **Overview** tab, copy the **Application Audience (AUD) Tag**. +3. From the **Basic information** tab, copy the **Application Audience (AUD) Tag**. You can now paste the AUD tag into your token validation script. The AUD tag will never change unless you delete or recreate the Access application. diff --git a/src/content/docs/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication.mdx b/src/content/docs/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication.mdx index f43cdf87ffdb1f..e2a8df40633e8f 100644 --- a/src/content/docs/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication.mdx +++ b/src/content/docs/cloudflare-one/identity/devices/access-integrations/mutual-tls-authentication.mdx @@ -50,7 +50,7 @@ To enforce mTLS authentication from [Zero Trust](https://one.dash.cloudflare.com 7. Next, go to **Access** > **Applications**. -8. Find the application you would like to enforce mTLS on and select **Edit**. The application must be included in the **Associated hostnames** list from Step 5. +8. Find the application you would like to enforce mTLS on and select **Configure**. The application must be included in the **Associated hostnames** list from Step 5. 9. Create a new (or amend an existing) [Access policy](/cloudflare-one/policies/access/). diff --git a/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-gateway.mdx b/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-gateway.mdx index 2446897fc46104..1e2948fffe4390 100644 --- a/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-gateway.mdx +++ b/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-gateway.mdx @@ -11,13 +11,13 @@ head: import { Render } from "~/components" -With Require Gateway, you can allow access to your applications only to devices enrolled in your organization's instance of Gateway. Unlike [Require WARP](/cloudflare-one/identity/devices/warp-client-checks/require-warp/), which will check for any WARP instance (including the consumer version), Require Gateway will only allow requests coming from devices whose traffic is filtered by your organization's Cloudflare Gateway configuration. This policy is best used when you want to protect company-owned assets by only allowing access to employees. +With Require Gateway, you can allow access to your applications only to devices enrolled in your Zero Trust organization. Unlike [Require WARP](/cloudflare-one/identity/devices/warp-client-checks/require-warp/), which will check for any WARP instance (including the consumer version), Require Gateway will only allow requests coming from devices whose traffic is filtered by your organization's Cloudflare Gateway configuration. This policy is best used when you want to protect company-owned assets by only allowing access to employees. ## Prerequisites * -## Enable the Gateway check +## 1. Enable the Gateway check 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Settings** > **WARP Client**. @@ -25,14 +25,16 @@ With Require Gateway, you can allow access to your applications only to devices 3. Select **Gateway**, then select **Save**. -## Add the check to an Access policy +## 2. Add the check to an Access application 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Select the application for which you want to require Gateway, then select **Configure**. +2. Locate the application for which you want to require Gateway. Select **Configure**. -3. To create a new Access policy, select **Add a policy**. To require Gateway for an existing policy, select a policy, then select **Configure**. +3. In the **Policies** tab, create a new Access policy or edit an existing policy. -4. Add an Include or Require rule which uses the Gateway selector. Select **Save policy**. +4. In the policy builder, add an Include or Require rule which uses the _Gateway_ selector. Save the policy. -Before granting access to the application, your policy will now check that the device is running the WARP client and enrolled in your Zero Trust organization. +5. Save the Access application. + +Before granting access to the application, the policy will check that the device is running the WARP client and enrolled in your Zero Trust organization. diff --git a/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-warp.mdx b/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-warp.mdx index a18892af75cbff..ce575c1a16d2c4 100644 --- a/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-warp.mdx +++ b/src/content/docs/cloudflare-one/identity/devices/warp-client-checks/require-warp.mdx @@ -29,22 +29,20 @@ Cloudflare Zero Trust enables you to restrict access to your applications to dev 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Settings** > **Network**. 2. Ensure that **Proxy** is enabled. -3. Next, go to **Settings** > **WARP Client**. -4. Scroll down to **WARP client checks** and select **Add new**. -5. Select **WARP**. - -You are now ready to start requiring WARP for your Access applications. +3. Go to **Settings** > **WARP Client**. +4. In **WARP client checks**, select **Add new**. +5. Select **WARP**, then select **Save**. ## 2. Add the check to an Access policy 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Locate the application for which you want to require WARP. +2. Locate the application for which you want to require WARP. Select **Configure**. -3. Select **Edit**. +3. In the **Policies** tab, create a new Access policy or edit an existing policy. -4. To have an existing policy require WARP, select **Edit** for that specific policy. Then, add an **Include** or **Require** rule which uses the *WARP* selector. +4. In the policy builder, add an Include or Require rule which uses the _WARP_ selector. Save the policy. -5. Select **Save rule**. +5. Save the Access application. -Before granting access to the application, your policy will now check that the device is running the WARP client. +Before granting access to the application, the policy will check that the device is running the WARP client. diff --git a/src/content/docs/cloudflare-one/identity/users/session-management.mdx b/src/content/docs/cloudflare-one/identity/users/session-management.mdx index e97796abc04bdf..2d9ad22312f474 100644 --- a/src/content/docs/cloudflare-one/identity/users/session-management.mdx +++ b/src/content/docs/cloudflare-one/identity/users/session-management.mdx @@ -32,6 +32,7 @@ You can set a global session duration between 15 minutes and 1 month. 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Settings** > **Authentication**. 2. Under **Global session timeout**, select **Edit**, 3. Select the desired timeout duration from the dropdown menu. +4. Select **Save**. The user will be required to re-authenticate with the IdP after this period of time. @@ -40,8 +41,9 @@ The user will be required to re-authenticate with the IdP after this period of t You can set an application session duration for self-hosted and private Access applications. Available session durations range from immediate timeout to 1 month. The default is 24 hours. 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Locate the application you want to configure and select **Edit**. -3. In the **Overview** tab, select a **Session Duration** from the dropdown menu. +2. Choose an application and select **Configure**. +3. Select a **Session Duration** from the dropdown menu. +4. Save the application. The application token will expire after this period of time (unless you have set a [policy session duration](#set-policy-session-duration)). @@ -56,6 +58,7 @@ You can set a policy session duration ranging from immediate timeout to one mont 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Policies**. 2. Choose a policy and select **Configure**. 3. Select a **Session Duration** from the dropdown menu. +4. Save the policy. Users who match this policy will be issued an application token with this expiration time. @@ -69,9 +72,9 @@ To immediately terminate all active sessions for a specific application: 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Locate the application for which you would like to revoke active sessions and select **Edit**. +2. Locate the application for which you would like to revoke active sessions and select **Configure**. -3. In the **Overview** tab, select **Revoke existing tokens**. +3. Select **Revoke existing tokens**. Unless there are changes to rules in the policy, users can start a new session if their profile in your identity provider is still active. diff --git a/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx b/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx index 5ab03830f9e99e..b37e4d0ce38531 100644 --- a/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx +++ b/src/content/docs/cloudflare-one/policies/access/mfa-requirements.mdx @@ -18,21 +18,25 @@ This feature is only available if you are using the following identity providers To enforce an MFA requirement to an application: -1. In Zero Trust, go to **Access** > **Applications**. +1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. -2. Find the application for which you want to enforce MFA and select **Edit**. Alternatively, [create a new application](/cloudflare-one/applications/configure-apps/). +2. Find the application for which you want to enforce MFA and select **Configure**. Alternatively, [create a new application](/cloudflare-one/applications/configure-apps/). -3. Go to the **Rules** section of the application. +3. Go to **Policies**. -4. If your application already has a rule containing an identity requirement, find it and select **Edit**. +4. If your application already has a policy containing an identity requirement, find it and select **Configure**. - The rule must contain an Include rule which defines an identity. For example, the Include rule should allow for users who are part of a [rule group](/cloudflare-one/policies/access/groups/), email domain, or identity provider group. + :::note + The policy should contain an Include rule that uses identity-based selectors. For example, the Include rule could allow users who are part of a [rule group](/cloudflare-one/policies/access/groups/), email domain, or identity provider group. + ::: -5. Add a _Require_ action to the rule. +5. Add the following rule to the policy: -6. Select _Authentication Method_ and choose `mfa - multiple-factor authentication`. + | Rule type | Selector | Value | + | ---------- | -------- | ------ | + | Require | Authentication method | `mfa - multiple-factor authentication` | -7. Save the rule. +6. Save the policy. :::caution[Important] diff --git a/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx b/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx index 6da5c3eab79857..793f7c9475f7f1 100644 --- a/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx +++ b/src/content/docs/cloudflare-one/policies/access/require-purpose-justification.mdx @@ -1,26 +1,28 @@ --- pcx_content_type: how-to -title: Require Purpose Justification +title: Require purpose justification sidebar: order: 3 head: - tag: title - content: Require Purpose Justification after login + content: Require purpose justification after login --- -Cloudflare Access allows security and IT teams to present users with a purpose justification screen directly after they log in to an Access application. This allows organizations to audit not only for *who* is accessing their resources, but also for *why* they are requesting access. +Cloudflare Access allows security and IT teams to present users with a purpose justification screen directly after they log in to an Access application. This allows organizations to audit not only for who is accessing their resources, but also for why they are requesting access. The purpose justification screen will show for any new sessions of an application. For example, if an Access application has a session time of eight hours, a user will see the purpose justification screen once every eight hours. Configuring a purpose justification screen is done as part of configuring an Access policy. -1. In Zero Trust, go to **Access** > **Applications**. -2. Select an application and select **Edit**. -3. Select the policy you want to configure with purpose justification. -4. Open **Optional Configurations**. -5. Enable purpose justification. -6. (Optional) set a custom purpose justification message. This will appear on the purpose justification screen and will be visible to the user. -7. Once configured, a user will see the following screen: +1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. +2. Choose an application and select **Configure**. +3. Go to **Policies**. +4. Choose an **Allow** policy and select **Configure**. +5. Under **Additional settings**, turn on **Purpose justification**. +6. (Optional) Set a custom purpose justification message. This will appear on the purpose justification screen and will be visible to the user. +7. Save the policy. + +Users who match this policy will see the following screen: ![Finalized purpose justification screen displaying custom message.](~/assets/images/cloudflare-one/policies/purpose-justification.png) diff --git a/src/content/docs/cloudflare-one/policies/access/temporary-auth.mdx b/src/content/docs/cloudflare-one/policies/access/temporary-auth.mdx index 242c27cec5baf2..5b24cd305f50bd 100644 --- a/src/content/docs/cloudflare-one/policies/access/temporary-auth.mdx +++ b/src/content/docs/cloudflare-one/policies/access/temporary-auth.mdx @@ -11,11 +11,14 @@ With Cloudflare Access, you can require that users obtain approval before they c ## Set up temporary authentication 1. In [Zero Trust](https://one.dash.cloudflare.com), go to **Access** > **Applications**. -2. Choose a **Self-hosted** or **SaaS** application and select **Edit**. -3. Choose the **Allow** policy you want to configure and select **Edit**. +2. Choose a **Self-hosted** or **SaaS** application and select **Configure**. +3. Choose an **Allow** policy and select **Configure**. 4. Under **Additional settings**, turn on [**Purpose justification**](/cloudflare-one/policies/access/require-purpose-justification/). 5. Turn on **Temporary authentication**. -6. Enter the **Email addresses of the approvers**. (Note: your approvers must be authenticated by Access. If they do not have an active session, Access will verify their identity against your [App Launcher Access policy](/cloudflare-one/applications/app-launcher/).) +6. Enter the **Email addresses of the approvers**. + :::note + Your approvers must be authenticated by Access. If they do not have an active session, Access will verify their identity against your [App Launcher Access policy](/cloudflare-one/applications/app-launcher/). + ::: 7. Save the policy. Temporary authentication is now enabled for users who match this policy. You can optionally add a second **Allow** policy for users who should have persistent access. Be sure the policy order is set to allow persistent users through. diff --git a/src/content/partials/cloudflare-one/access/app-launcher.mdx b/src/content/partials/cloudflare-one/access/app-launcher.mdx index 21dab17962a696..214fe491c5f7ba 100644 --- a/src/content/partials/cloudflare-one/access/app-launcher.mdx +++ b/src/content/partials/cloudflare-one/access/app-launcher.mdx @@ -38,21 +38,21 @@ To show an Access application in the App Launcher: 1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. 2. Select an application and select **Configure**. -3. In the **Overview** tab, select **Enable App in App Launcher**. The App Launcher link will only appear for users who are allowed by your Access policies. Blocked users will not see the app in their App Launcher. +3. Go to **Experience settings**. +4. Select **Show application in App Launcher**. The App Launcher link will only appear for users who are allowed by your Access policies. Blocked users will not see the app in their App Launcher. -:::note + :::note -This toggle does not impact the user's ability to reach the application. Allowed users can always reach the application via a direct link, regardless of whether the toggle is enabled. Blocked users will never have access to the application. -::: + This toggle does not impact the user's ability to reach the application. Allowed users can always reach the application via a direct link, regardless of whether the toggle is enabled. Blocked users will never have access to the application. + ::: -4. Choose a domain to use for the App Launcher link. +5. (Optional) To use a custom logo for the application tile, select **Use custom logo** and enter a link to your desired image. -5. To use a custom logo for the application tile, select **Custom** and enter a link to your desired image. + :::note + If you are having issues specifying a custom logo, check that the image is served from an HTTPS endpoint. For example, `http://www.example.com/upload/logo.png` will not work. However, `https://www.example.com/upload/logo.png` will. + ::: -:::note - -If you are having issues specifying a custom logo, check that the image is served from an HTTPS endpoint. For example, `http://www.example.com/upload/logo.png` will not work. However, `https://www.example.com/upload/logo.png` will. -::: +6. In **Application domains**, choose a domain to use for the App Launcher link. ## Customize App Launcher appearance diff --git a/src/content/partials/cloudflare-one/access/enable-isolation.mdx b/src/content/partials/cloudflare-one/access/enable-isolation.mdx index cc58c670e38631..9717d8b73b5a79 100644 --- a/src/content/partials/cloudflare-one/access/enable-isolation.mdx +++ b/src/content/partials/cloudflare-one/access/enable-isolation.mdx @@ -7,11 +7,12 @@ import { Render } from "~/components" -3. Next, go to **Access** > **Applications**. +3. Go to **Access** > **Applications**. 4. Choose a [self-hosted application](/cloudflare-one/applications/configure-apps/self-hosted-public-app/) and select **Configure**. -5. Choose an [Allow policy](/cloudflare-one/policies/access/) and select **Configure**. -6. Under **Additional settings**, turn on **Isolate application**. -7. Save the policy. +5. Go to **Policies**. +6. Choose an [Allow policy](/cloudflare-one/policies/access/) and select **Configure**. +7. Under **Additional settings**, turn on **Isolate application**. +8. Save the policy. Browser Isolation is now enabled for users who match this policy. After the user logs into Access, the application will launch in a remote browser. To confirm that the application is isolated, refer to [Check if a web page is isolated](/cloudflare-one/policies/browser-isolation/setup/#3-check-if-a-web-page-is-isolated). diff --git a/src/content/partials/cloudflare-one/access/tags.mdx b/src/content/partials/cloudflare-one/access/tags.mdx index 19681a56d28fae..f64172dc69b6ef 100644 --- a/src/content/partials/cloudflare-one/access/tags.mdx +++ b/src/content/partials/cloudflare-one/access/tags.mdx @@ -22,7 +22,7 @@ To add a tag to an existing Access application: 1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Applications**. 2. Select an application and select **Configure**. -3. Select the **Overview** tab. +3. Go to **Experience settings**. 4. In the **Tags** dropdown, select the tags that you would like to assign to this application. The tag must be [created](#create-a-tag) before you can select it in the dropdown. 5. Select **Save application**.