Using hostname and path conditions

This page describes hostname and path Identity and Access Management (IAM) conditions.

You can secure Identity-Aware Proxy (IAP) resources using the hostname and path of a request URL. For example, the request.path.startsWith IAM condition can be used to only grant access to employees in the Privileged Access group if the URL path starts with /admin.

For more information about using hostname and path conditions, see request attributes.

String normalization

A URL has a hostname and path. For example, the URL https://sheets.google.com/create?query=param has a hostname of sheets.google.com and a path of /create.

Backends can interpret hostnames and paths in different ways. To remove ambiguity, IAP normalizes hostname and path strings when checking policies.

IAP performs two policy checks when a request has a non-normalized path. If the non-normalized path passes the policy check, IAP normalizes the path and a second policy check is performed. Access is granted if both the non-normalized and normalized paths pass the policy check.

For example, if a request has the path /internal;some_param/admin, IAP first performs a policy check on the non-normalized path (/internal). If that check passes, IAP performs a second policy check on the normalized path (/internal/admin).

Hostnames

Hostname normalization involves the following:

  • Removing trailing dots
  • Lowercasing characters
  • Converting to ASCII

Hostnames that include non-ASCII characters are further normalized using Punycode. You need to use Punycode to normalize your hostname string for a match to be made.

To normalize your hostname string with Punycode, use a converter like Punycoder.

The following are examples of normalized hostnames:

  • FOO.com is normalized to foo.com
  • café.fr is normalized to xn--caf-dma.fr

Paths

Path normalization involves the following:

  • Removing path params
  • Resolving relative paths to their absolute equivalent

A path param includes all characters from a ; to either the next / or the end of the path.

Requests that contain path sections starting with ..; are considered invalid. For example, /..;bar/ and /bar/..;/ return the HTTP 400: Bad Request error.

The following are examples of normalized paths:

  • /internal;some_param/admin is normalized to /internal/admin
  • /a/../b is normalized to /b
  • /bar;param1/baz;baz;param2 is normalized to /bar/baz

Subdomain endings

A policy set with request.host.endsWith("google.com") matches to both sub_domain.google.com and testgoogle.com. If your goal is to limit your policy to only subdomains that end with google.com, set your policy to request.host.endsWith(".google.com").