Move Access up one level

Author: maxvp

public/__redirects

@@ -2387,7 +2387,7 @@
 /cloudflare-one/policies/gateway/* /cloudflare-one/traffic-policies/:splat 301
 /cloudflare-one/policies/browser-isolation/* /cloudflare-one/remote-browser-isolation/:splat 301
 /cloudflare-one/policies/data-loss-prevention/* /cloudflare-one/data-loss-prevention/:splat 301
-/cloudflare-one/policies/access/* /cloudflare-one/access-controls/policies/access/:splat 301
+/cloudflare-one/policies/access/* /cloudflare-one/access-controls/policies/:splat 301
 /cloudflare-one/api-terraform/* /cloudflare-one/access-controls/policies/api-terraform/:splat 301
 
 # Learning paths

src/content/docs/cloudflare-one/access-controls/policies/app-paths.mdx

@@ -0,0 +1,92 @@
+---
+pcx_content_type: concept
+title: Application paths
+sidebar:
+  order: 5
+
+---
+
+Application paths define the URLs protected by an Access policy. When adding a self-hosted application to Access, you can choose to protect the entire website by entering its apex domain, or alternatively, protect specific subdomains and paths.
+
+## Policy inheritance
+
+Cloudflare Zero Trust allows you to create unique rules for parts of an application that share a root path. Imagine an example application is deployed at `dashboard.com/eng` that anyone on the engineering team should be able to access. However, a tool deployed at `dashboard.com/eng/exec` should only be accessed by the executive team.
+
+When multiple rules are set for a common root path, the more specific rule takes precedence. For example, when setting rules for `dashboard.com/eng` and `dashboard.com/eng/exec` separately, the more specific rule for `dashboard.com/eng/exec` takes precedence, and no rule is inherited from `dashboard.com/eng`. If no separate, specific rule is set for `dashboard.com/eng/exec`, it will inherit any rules set for `dashboard.com/eng`.
+
+## Wildcards
+
+When you create an application for a specific subdomain or path, you can use asterisks (`*`) as wildcards. Wildcards allow you to extend the application you are creating to multiple subdomains or paths in a given apex domain.
+
+### Examples
+
+#### Match all subdomains of an apex domain
+
+A wildcard in the **Subdomain** field only matches that specific subdomain level. It does not cover the apex domain or multiple levels of the subdomain. If you want to cover multiple subdomain levels, you can use multiple wildcards.
+
+| Application     | Covers                                       | Does not cover |
+| --------------- | -------------------------------------------- | -------------- |
+| `*.example.com` | `alpha.example.com` <br/> `beta.example.com` | `example.com` <br/> `foo.bar.example.com`  |
+
+#### Match all paths of an apex domain
+
+To protect an apex domain and all of the paths under it, leave the **Path** field empty. Alternatively, use a wildcard in the **Path** field.
+
+| Application                            | Covers                                                           | Does not cover      |
+| -------------------------------------- | ---------------------------------------------------------------- | ------------------- |
+| `example.com` <br/> or `example.com/*` | `example.com` <br/> `example.com/alpha` <br/> `example.com/beta` | `alpha.example.com` |
+
+#### Match multi-level subdomains
+
+Using a wildcard in the **Subdomain** field does not cover the parent subdomain nor the apex domain.
+
+| Application          | Covers                                                 | Does not cover                          |
+| -------------------- | ------------------------------------------------------ | --------------------------------------- |
+| `*.test.example.com` | `alpha.test.example.com` <br/> `beta.test.example.com` | `test.example.com`  <br/> `example.com` |
+
+#### Partially match subdomains
+
+Using a wildcard at the beginning or end of the **Subdomain** field does not cover multiple levels of the subdomain.
+
+| Application         | Covers                                           | Does not cover          |
+| ------------------- | ------------------------------------------------ | ----------------------- |
+| `*test.example.com` | `test.example.com` <br/> `alphatest.example.com` | `beta.test.example.com` |
+
+#### Match multi-level paths
+
+Using a wildcard in the **Path** field does not cover the parent path nor the apex domain.
+
+| Application           | Covers                                                | Does not cover                          |
+| --------------------- | ----------------------------------------------------- | --------------------------------------- |
+| `example.com/alpha/*` | `example.com/alpha/one` <br/> `example.com/alpha/two` | `example.com/alpha` <br/> `example.com` |
+
+#### Partially match paths
+
+Using a wildcard in the middle of the **Path** field covers multiple segments of the URL.
+
+| Application            | Covers                                                                               |
+| ---------------------- | ------------------------------------------------------------------------------------ |
+| `example.com/foo*/bar` | `example.com/foo/bar`<br/> `example.com/food/bar` <br/> `example.com/food/stuff/bar` |
+
+### Limitations
+
+* At most one wildcard in between each dot in the **Subdomain**. For example, `foo*bar*baz.example.com` is not allowed.
+* At most one wildcard in between each slash in the **Path**. For example, `example.com/foo*bar*baz` is not allowed.
+
+## Subdomain setups
+
+[Subdomain setups](/dns/zone-setups/subdomain-setup/) allow you to manage a child domain separately from its parent domain. In Access application paths, your configured child domains will appear in the **Domain** dropdown menu. If you [split out a subdomain](/dns/zone-setups/subdomain-setup/setup/) which already has an Access application, you will need to re-save the Access application to associate it with the new child domain.
+
+## Unsupported URLs
+
+### Port numbers
+
+Port numbers are not supported in Access application paths. If a request includes a port number in the URL, Access will strip the port number and redirect the request to the default HTTP/HTTPS port.
+
+### Query strings
+
+Query strings (such as`?foo=bar`) are not supported in Access application paths.
+
+### Anchor links
+
+Since anchor links are processed by the browser and not the server, Access applications do not support `#` characters in the URL. For example, requests to `dashboard.com/#settings` will redirect to `dashboard.com`.

src/content/docs/cloudflare-one/access-controls/policies/external-evaluation.mdx

@@ -0,0 +1,181 @@
+---
+pcx_content_type: how-to
+title: External Evaluation rules
+sidebar:
+  order: 4
+---
+
+import { GlossaryTooltip, Example, WranglerConfig, DashButton } from "~/components";
+
+With Cloudflare Access, you can create Allow or Block policies which evaluate the user based on custom criteria. This is done by adding an **External Evaluation** rule to your policy. The **External Evaluation** selector requires two values:
+
+- **Evaluate URL** — the API endpoint containing your business logic.
+- **Keys URL** — the key that Access uses to verify that the response came from your API
+
+After the user authenticates with your identity provider, Access sends the user's identity to the external API at **Evaluate URL**. The external API returns a True or False response to Access, which will then allow or deny access to the user. To protect against man-in-the-middle attacks, Access signs all requests with your Access account key and checks that responses are signed by the key at **Keys URL**.
+
+You can set up External Evaluation rules using any API service, but to get started quickly we recommend using [Cloudflare Workers](/workers/).
+
+## Set up external API and key with Cloudflare Workers
+
+### Prerequisites
+
+- [Workers account](/workers/get-started/guide/)
+- Install [npm](https://docs.npmjs.com/getting-started)
+- Install [Node.js](https://nodejs.org/en/)
+- Application protected by Access
+
+### 1. Create a new Worker
+
+1. Open a terminal and clone our example project.
+
+   ```sh
+   npm create cloudflare@latest my-worker -- --template https://github.com/cloudflare/workers-access-external-auth-example
+   ```
+
+2. Go to the project directory.
+
+   ```sh
+   cd my-worker
+   ```
+
+3. Create a [Workers KV namespace](/kv/concepts/kv-namespaces/) to store the key. The binding name should be `KV` if you want to run the example as written.
+
+   ```sh
+   npx wrangler kv namespace create "KV"
+   ```
+
+   The command will output the binding name and KV namespace ID, for example
+
+   ```txt
+     [[kv_namespaces]]
+      binding = "KV"
+      id = "YOUR_KV_NAMESPACE_ID"
+   ```
+
+4. Open the [Wrangler configuration file](/workers/wrangler/configuration/) in an editor and insert the following:
+
+   - `[[kv_namespaces]]`: Add the output generated in the previous step.
+   - `<TEAM_NAME>`: your Cloudflare Zero Trust <GlossaryTooltip term="team name">team name</GlossaryTooltip>.
+
+  <WranglerConfig>
+
+   ```toml
+   name = "my-worker"
+   workers_dev = true
+   compatibility_date = "2024-08-06"
+   main = "index.js"
+
+
+   [[kv_namespaces]]
+   binding = "KV"
+   id = "YOUR_KV_NAMESPACE_ID"
+
+   [vars]
+   TEAM_DOMAIN="<TEAM_NAME>.cloudflareaccess.com"
+   DEBUG=false
+   ```
+	 </WranglerConfig>
+
+### 2. Program your business logic
+
+1. Open `index.js` and modify the `externalEvaluation` function to perform logic on any identity-based data sent by Access.
+
+:::note
+
+- Sample code is available in our [GitHub repository](https://github.com/cloudflare/workers-access-external-auth-example).
+- To view a list of identity-based data fields, log in to your Access application and append `/cdn-cgi/access/get-identity` to the URL. For example, if `www.example.com` is behind Access, visit `https://www.example.com/cdn-cgi/access/get-identity`.
+  :::
+
+2. Deploy the Worker to Cloudflare's global network.
+
+   ```sh
+   npx wrangler deploy
+   ```
+
+The Worker will be deployed to your `*.workers.dev` subdomain at `my-worker.<YOUR_SUBDOMAIN>.workers.dev`.
+
+### 3. Generate a key
+
+To generate an RSA private/public key pair:
+
+1. Open a browser and go to `https://my-worker.<YOUR_SUBDOMAIN>.workers.dev/keys`.
+
+2. (Optional) Verify that the key has been stored in the `KV` namespace:
+   1. In the Cloudflare dashboard, go to the **Workers KV** page.
+			<DashButton url="/?to=/:account/workers/kv/namespaces" />
+   2. Select **View** next to `my-worker-KV`.
+
+Other key formats (such as DSA) are not supported at this time.
+
+### 4. Create an External Evaluation rule
+
+1. In [Zero Trust](https://one.dash.cloudflare.com/), go to **Access** > **Policies**.
+
+2. Edit an existing policy or select **Add a policy**.
+
+3. Add the following rule to your policy:
+
+| Rule Type | Selector            | Evaluate URL                                      | Keys URL                                               |
+| --------- | ------------------- | ------------------------------------------------- | ------------------------------------------------------ |
+| Include   | External Evaluation | `https://my-worker.<YOUR_SUBDOMAIN>.workers.dev/` | `https://my-worker.<YOUR_SUBDOMAIN>.workers.dev/keys/` |
+
+4. Save the policy.
+
+5. Go to **Access** > **Applications** and edit the application for which you want to apply the External Evaluation rule.
+
+6. In the **Policies** tab, add the policy that contains the External Evaluation rule.
+
+7. Select **Save application**.
+
+When a user logs in to your application, Access will now check their email, device, location, and other identity-based data against your business logic.
+
+### Troubleshooting the Worker
+
+To debug your External Evaluation rule:
+
+1. Go to your Worker directory.
+
+   ```sh
+   cd my-worker
+   ```
+
+2. Open the [Wrangler configuration file](/workers/wrangler/configuration/) in an editor and set the `debug` variable to `TRUE`.
+
+3. Deploy your changes.
+
+   ```sh
+   npx wrangler deploy
+   ```
+
+4. Next, start a session to output realtime logs from your Worker.
+
+   ```sh
+   wrangler tail -f pretty
+   ```
+
+5. Log in to your Access application.
+
+   The session logs should show an incoming and outgoing JWT. The incoming JWT was sent by Access to the Worker API, while the outgoing JWT was sent by the Worker back to Access.
+
+6. To decode the contents of a JWT, you can copy the token into [jwt.io](https://jwt.io/).
+
+   The incoming JWT should contain the user's identity data. The outgoing JWT should look similar to:
+
+   ```js
+   {
+   "success": true,
+   "iat": 1655409315,
+   "exp": 1655409375,
+   "nonce": "9J2E9Xg6wYj8tlnA5MV4Zgp6t8rzmS0Q"
+   }
+   ```
+
+   Access checks the outgoing JWT for all of the following criteria:
+
+   - Token was signed by **Keys URL**.
+   - Expiration date has not elapsed.
+   - API returns `"success": true`.
+   - `nonce` is unchanged from the incoming JWT. The `nonce` value is unique per request.
+
+   If any condition fails, the External Evaluation rule evaluates to false.

src/content/docs/cloudflare-one/access-controls/policies/groups.mdx

@@ -0,0 +1,32 @@
+---
+pcx_content_type: concept
+title: Rule groups
+sidebar:
+  order: 2
+---
+
+import { Render } from "~/components";
+
+A rule group is a collection of Access rules that can be configured once and then quickly applied across many Access policies. Rule groups use the same [rule types](/cloudflare-one/access-controls/policies/#rule-types) and [selectors](/cloudflare-one/access-controls/policies/#selectors) shown in the Access policy builder.
+
+:::note
+Rule groups are distinct from groups in your identity provider, like Okta groups. Rule groups can contain a mix of individual users, groups from identity providers, and service authentication options like service tokens.
+:::
+
+## Create a rule group
+
+<Render file="access/rule-group" product="cloudflare-one" />
+
+## Use cases
+
+### IP-based rules
+
+We recommend using rule groups to define any IP address-based rules you configure in policies. Keeping IP addresses in one place allows you to modify or remove addresses once, rather than in each policy, and reduces the potential for mistakes.
+
+:::note
+If adding more than one IP address or range to a rule group, use an Include rule for the IPs. If you do not use an Include rule, the policy will require traffic to originate from all ranges.
+:::
+
+### Country requirements
+
+You can create a rule group that consists of countries to allow or block. Access will treat the countries in the Include rule with an OR logical operator. When building policies for an Access application, you can assign this rule group to a Require policy to require at least one of the countries inside of the group. For an example policy, refer to [Require rules with OR operators](/cloudflare-one/access-controls/policies/#require-rules-with-or-operators).