Authentication policy

The Authentication Policy page (route /auth-issuer-policy) is the global control for what happens during the authentication flow: which multi-factor authentication methods are allowed, how long credentials live, which preset security posture to apply, and the ordered rules that decide whether a user may sign in. Authorisation happens per application, but authentication is global, and this page is where it is governed.

Purpose

Authentication policy applies to every sign-in through your issuer. It has four parts:

Multi-factor authentication methods: which second-factor methods are enabled (time-based challenge apps and WebAuthn).
Credential policy: the maximum lifetime for credentials, globally and per resource type.
Authentication rules: preset security postures (Default, Permissive, Strict) that you can configure and apply, plus a default action for sign-in attempts that match no rule.
Policy groups and rules: named groups of ordered rules. Each rule has conditions and an action, and the first rule whose conditions match decides the outcome.

For organisations that inherit their issuer from a parent (a sub-organisation without a unique issuer), the page shows Inherited Policy: Yes and the controls are disabled.

Why use it

Enforce multi-factor authentication consistently across every application, including legacy ones (see Identity and authentication).
Set a security posture in one step with the Default, Permissive, or Strict presets.
Write precise rules, for example deny sign-in from a specific IP range, require multi-factor authentication for a specific application or group, or allow single sign-on only for certain clients.
Limit credential lifetime so stale tokens cannot be used.

When to use it

During initial setup, to choose a preset and confirm the multi-factor authentication methods your users can enrol.
When your organisation needs a stronger or weaker posture, or a specific rule for a group of users or a client.
After a security review, to enforce shorter credential lifetimes.

Prerequisite: permission to administer issuers (an owner or administrator role). The page shows a no permissions message otherwise.

How to use it

Open Authentication > Authentication Policy from the left navigation.
Confirm the Multi-Factor Authentication Methods Enabled checkboxes match what you support: Time based challenge app (a one-time code from an authenticator application) and WebAuthn (a security key or platform authenticator).
Select CREDENTIAL POLICY to set the maximum lifetime for credentials, globally and per resource type.

In the Authentication Rules cards, select CONFIG & APPLY PRESET on a preset to review and apply it. The more menu on a card shows See detailed Information for the preset.

Set the Default Action that applies when no rule matches.

Organise rules into policy groups with ADD GROUP, or expand an existing group to manage its rules.

Working with rules

Within a group, each rule has a Rule Name, an Action (for example Authenticate with an identity provider), and a set of conditions. Rules are evaluated in order; the first rule whose conditions all match wins.

ADD RULE creates a new rule in the group.
ADD CONDITION opens the condition wizard.
Tick conditions and select DELETE CONDITIONS to remove them.
DELETE RULE removes the whole rule.
DELETE GROUP removes the group and its rules.

Creating a condition

Select ADD CONDITION to open the Configure Policy Condition wizard.

Choose condition type. Select the condition type: Client id, IP in CIDR, Successful Multi-Factor Login, Object attribute, Org id, Upstream identity provider, User has enrolled Multi-Factor method, or User id.

For Object attribute, also choose a field to compare, for example login session user is authenticated or user member of email.

Configure condition details. The wizard shows the chosen condition type and field, then asks for an operator and a value. Operators are equals, greater than, in, less than, not equals, and not in.

Apply and Done. Select Add on the Apply step to save the condition to the rule.

The condition appears in the rule’s condition table. Its row menu offers Configure Condition to edit it.

Fields and controls reference

Control	Purpose	Required	Default	Valid values	Notes
Inherited Policy	Whether this organisation shares its parent’s policy	Read-only	No	Yes or No	Yes disables the configuration controls
Time based challenge app	Enables time-based one-time codes (for example Google Authenticator, Authy)	No	On	On or off
WebAuthn	Enables WebAuthn (USB security key, push to phone, biometric, TPM)	No	On	On or off
CREDENTIAL POLICY	Opens the credential lifetime dialog	n/a	n/a	n/a
Default Action	The action when no rule matches	Yes	Deny Login	Require Second Factor; Deny Login; Allow Login; Authenticate with an identity provider
CONFIG & APPLY PRESET	Applies a Default, Permissive, or Strict preset	n/a	n/a	n/a	Opens the preset configuration dialog
ADD GROUP	Creates a new policy group	n/a	n/a	n/a
ADD RULE	Creates a new rule in a group	n/a	n/a	n/a
ADD CONDITION	Opens the condition wizard	n/a	n/a	n/a
DELETE CONDITIONS	Removes the ticked conditions from a rule	n/a	n/a	n/a
DELETE RULE	Removes a rule	n/a	n/a	n/a
DELETE GROUP	Removes a group and its rules	n/a	n/a	n/a
Action (rule)	The action the rule takes when its conditions match	Yes	Authenticate with an identity provider	The multi-factor challenge answer results

Credential policy dialog

Control	Purpose	Valid values
Global Default Maximum Lifetime (Hours)	The fallback lifetime for credentials when no specific scope is set	A number of hours
Ssh, Shares, Applications, Databases, Desktops, Networks	Per-resource-type maximum lifetimes	A number of hours per scope

Preset configuration dialog

Control	Purpose
Multi factor required time interval (time in seconds)	How often multi-factor authentication is required
Sessions valid for (time in seconds)	How long a session lasts
Allow shared sessions between applications	Whether a session carries across applications
Does not require multi factor authentication from providers	Providers exempt from multi-factor authentication (Select Providers)
Always require multi factor authentication for applications	Applications that always require multi-factor authentication (Select Applications)
Always require multi factor authentication for groups	Groups that always require multi-factor authentication (Select Groups)
Apply	Applies the preset values to the policy

Dialogs and popups

Credential policy: the CREDENTIAL POLICY button opens the credential lifetime dialog described above.
Auth preset: CONFIG & APPLY PRESET opens the preset configuration dialog; its more menu opens the preset details information dialog, which has a Config & Apply Preset button that leads on to the configuration dialog.
Policy condition: ADD CONDITION opens the four-step condition wizard described above.

Configuration versus diagnostics versus confirmation

Configuration: the multi-factor authentication methods, credential policy, presets, default action, and the policy groups and rules.
Diagnostics: the inherited policy indicator is informational; there are no live diagnostics on this screen.
Confirmation: DELETE RULE and DELETE GROUP remove policy immediately. CONFIG & APPLY PRESET overwrites the policy with the preset’s settings, so review the preset dialog before applying. Changes to authentication policy affect every user sign-in.

Pagination and async behaviour

There is no table with paging on this screen; rules are organised into expandable groups.
Policy changes save asynchronously. After applying a preset, adding a rule, or changing the default action, wait a few seconds and reload to confirm. Sign-in behaviour changes as the policy propagates to the identity-aware proxy.

Troubleshooting

The controls are disabled: the organisation has an inherited policy (Inherited Policy: Yes). Give it a unique issuer to configure its own policy (see Sub-organisations).
A rule is not having an effect: check the rule’s order (rules are evaluated top to bottom) and its conditions. Use Configure Condition to verify each condition’s operator and value.
Multi-factor authentication is not offered: confirm at least one method is enabled here, and that the user has enrolled a method. See Multi-factor authentication.
Sign-in is denied unexpectedly: review the Default Action and the policy groups. The default in the demo organisation is Deny Login, so rules that allow authentication must match before the default applies.
I want to undo a preset: re-open the preset dialog and apply a different preset, or edit the individual rules.