IDPartnersidp-auth-peps · reference
Reference

Configuring the AuthZEN enforcement points

One page per component, every configurable item with its type, default and meaning, and a complete working configuration for each. Where a component has a screen, the screen is shown. Where it does not, what the setting produces is shown instead.

The components

Where each setting lives

Every enforcement point takes the same set of knobs, spelled the same way. What differs is only the channel they arrive through.

ComponentService-wide settingsPer-route settingsScreen
coaz-pepenvironment variablesext_authz context_extensions, or the config object of an HTTP checknone; its effects show in the demo console and in the documents it serves
Envoy · Istio · agentgatewaythe coaz-pep deployment's environmentcontext_extensions in the filter, the EnvoyFilter, or the agentgateway policy contextnone
Kong plugin—plugin config on a route or serviceKong Manager
Kong sideband plugin—plugin config on a route or serviceKong Manager
PingAccess rule—the rule's configuration, attached to an application's API policythe PingAccess console
Node SDKclient optionsmiddleware, guard and per-call optionsnone

Settings every PEP shares

These names mean the same thing on every surface. Each component page lists them again with that component's spelling, defaults and channel.

SettingWhat it decides
authzen_url / AUTHZEN_URLThe static PDP. It decides when discovery is off or a resource publishes nothing, it is always permitted, and it is the one PDP that receives the configured API key.
stylerest maps an HTTP request to an evaluation; mcp treats the route as an MCP edge and authorises JSON-RPC.
require_tokenDeny a request that carries no readable access token.
require_dpopEnforce the RFC 9449 sender constraint. Kong and PingAccess delegate the proof check to coaz-pep.
require_user_login, stepup_scope, stepup_actionThe RFC 9470 challenges: demand a logged-in end user, and a consented scope for a named action.
mcp_upstream_urlThe MCP server whose tools/list declares the COAZ mappings. Setting it enables per-tool-call authorisation.
pdp_discovery / PDP_DISCOVERYoff, authzen, resource, or (coaz-pep only) federation. How the PDP is found.
resourceThe protected resource's identifier, RFC 8707. The key discovery starts from.
pdp_allowlist, resource_metadata_allowlistWhat discovery may reach: which PDPs a document may name, which resources may be looked up.
forward_access_tokenHand the PDP the raw token as context.access_token. Only over a TLS, authenticated PDP connection.
pdp_layers, fail_modeThe ordered PDPs to ask, every one of which must permit, and what a layer does when its PDP cannot be reached.
federation_entity_url / FEDERATION_ENTITY_IDServe the resource's two well-known documents: coaz-pep holds the key; Kong and PingAccess relay from it.
coaz_defaults, legacy_subject_identityDecide every MCP method with the COAZ binding's default mappings where nothing is declared — on by default, false opts out; keep sending the pre-AuthZEN subject.identity field.
allow_insecure / PEP_ALLOW_INSECURE / allowInsecureStart, or accept a configuration, despite missing security settings — logged every time. Every PEP refuses without it. Development and demos only.

What has a screen

Two of the five surfaces have a console: Kong Manager shows a plugin's configuration, and the PingAccess console draws a form from the rule's descriptor. Both are captured on their pages. coaz-pep, the Envoy family and the Node SDK are configured in files and code, so there is no form to show. For those, the pages show what a setting produces: the startup log that names what is set, the well-known documents the PEP serves, and the demo console's trace of a request under that configuration.

Kong Manager showing the authzen-pdp plugin's configuration
Kong Manager, the plugin as Kong shows it. Every field on the Kong page.
The PingAccess console showing the AuthZEN PDP rule's form
The PingAccess console, the rule's form. Every field on the PingAccess page.

Conventions