Policies

IdRa has three kinds of sign-on policy, built from the same rules:

• Global Session Policy (Security → Global Session Policy): evaluated at every sign-in, on every request to IdRa, and each time a session reaches an app (OIDC, SAML, gateway). Decides who may hold a session, with which assurance, and for how long. An app's own policy runs after it.
• Authentication Policies (Security → Authentication Policies): decide access to apps. A Default Policy covers every app without its own; create app-specific policies with Choose an app, or a shared policy that many apps use.
• Admin Console Policy (Security → Admin Console Policy): extra rules for the admin console, on top of the MFA every administrator needs. See below.

RulesCopy Anchor Link

Rules are evaluated by priority (reorder with Move up / Move down). The first enabled rule that matches wins; if none matches, access is denied.

If (all conditions you set must match):

• User is a member of any of / User is not a member of groups;
• User is one of / User is not one of chosen people;
• App is any of / App type (OIDC, SAML, Bookmark, Gateway): authentication policies only, most useful on the default and shared policies;
• Expression: see Expressions in rules;
• Network zone: Anywhere / In any of these zones / Not in any of these zones;
• Risk is Low / Medium / High;
• Device: Any device / Managed / Not managed, and Platform (macOS, Windows, iOS, Android, Linux, ChromeOS);
• Device assurance policy is any of (see Devices).

Then:

• Access is Allowed / Denied;
• User must authenticate with Password / Password + another factor (MFA) / Phishing-resistant (passkey);
• Re-authenticate every (minutes): 0 = at every sign-in (MFA in the last 2 minutes counts), empty = once per session. Applies to the MFA and phishing-resistant levels; a password-only rule ignores it;
• Allowed methods: the session's latest factor must be one of these. Asked of MFA and phishing-resistant rules. Sessions verified with an emailed code before this setting shipped count as an authenticator app until they verify again;
• Two different factor types: something you know plus something you have. A passkey counts alone, because IdRa requires its PIN or biometric. Stricter than MFA after a step-up that replaced a passkey with a code;
• Maximum session lifetime (minutes): Global Session Policy only;
• Idle timeout (minutes): Global Session Policy only. Signed out after this long without a request to IdRa. Any request counts, including a tab left open that polls, and a person's first request after the rule is added starts the clock;
• People can sign in with Password / Passkey / Identity provider: Global Session Policy only. Other sign-ins are refused. SSO sign-ins are judged by the IdP and are never refused here, so choosing only Identity provider turns off passwords and passkeys.

When a rule needs more than the session has, people are sent to verify again (step-up) instead of being refused.

Expressions in rulesCopy Anchor Link

A rule can require an expression to be true. It reads user.* (profile attributes plus id, email, name, status) and the group functions.

• A missing attribute never grants access. !user.isContractor and user.department != "Sales" are true for someone without the attribute, so an allow rule that reads a missing attribute doesn't match, even if the result is true. That includes ?: fallbacks and OR branches it reads along the way. Compare explicitly (user.isContractor == false) and make sure the attribute is filled in.
• A deny rule does match on a missing attribute when its expression is true: !user.isEmployee denies someone without it. But user.isContractor == true is false for someone without it, so that deny rule doesn't stop them. To stop people with missing data, write the expression so missing data makes it true, or end the policy with a deny catch-all and allow by explicit attribute.
• An expression that fails at run time denies, on allow and deny rules alike, instead of moving to the next rule. Errors such as comparing a number with text, or a result that isn't true or false, count. Syntax is checked when you save.

Try a rule with the simulator before relying on it.

Shared policiesCopy Anchor Link

Authentication Policies → Add shared policy creates one set of rules, starting from a preset, and its page chooses the apps that use it. An app has one policy: an app with its own rules must have them deleted before it joins. A shared policy can't be deleted while apps use it. The Okta-compatible API doesn't show shared policies yet, and reports the default policy for an app that uses one.

Policy simulatorCopy Anchor Link

Security → Policy Simulator shows what a person would get opening an app or the admin console, given the network zones, platform, risk and factor you choose: each stage, the rule that decided, and why the rules above it didn't match. It changes nothing and logs nothing. It doesn't simulate session lifetime or idle timeouts, and it takes your input in place of a real device and network.

Admin Console PolicyCopy Anchor Link

With no rules, administrators need MFA and nothing more. Adding the first rule also adds a catch-all that asks for just that. Rules can require a passkey, allowed methods, a network zone or a device, or deny; none of them can remove the MFA requirement. API tokens aren't subject to it.

Saving a change to this policy or the Global Session Policy is refused if it would lock out the admin making it, from where they are now.

If administrators are locked out anyway, a super admin can open /login/console-recovery. It needs a sign-in, MFA in the last 10 minutes, and a network that isn't blocked. It deletes every Admin Console Policy rule and records policy.admin_console.recover in the System Log, with what was removed. Because it passes this policy on purpose, watch for that event. It only clears this policy: a Global Session Policy rule that refuses someone at sign-in has to be changed by another admin who can still get in.

DefaultsCopy Anchor Link

Administrators always need MFA, regardless of these rules. Rules with settings the Okta-compatible API can't express (people, apps, expressions, allowed methods, factor types, idle timeout, primary factors) can be read through it, without those settings, and PUT refuses them: edit them in the console.

Example: require a passkey for finance apps off-networkCopy Anchor Link

1. Networks → Add zone: an IP zone with your office CIDRs.
2. Authentication Policies → Add policy for the finance app, rule: User is a member of Finance, Network zone Not in Office, then Allowed, Phishing-resistant (passkey), re-authenticate every 60 minutes.
3. Keep a second, lower-priority rule allowing Finance with MFA from the office.

NetworksCopy Anchor Link

Security → Networks:

• IP zone: gateway IPs / CIDRs (IPv4 and IPv6).
• Dynamic zone: countries and ASNs. These need TRUST_PROXY=cloudflare (with Cloudflare's visitor location headers, and an X-ASN header for ASNs); forwarded provides the IP only.
• Block access from this zone (sign-in and every app) turns a zone into a blocklist.

A zone used by a rule can't be deleted. ThreatInsight appears as a read-only system entry.

Behavior detection and riskCopy Anchor Link

Security → Behavior Detection scores each sign-in:

A total of 25 or more is Medium risk, 50 or more is High. Use Risk is in rules to step up or deny risky sign-ins. Risk is also raised by IdRa Verify denials, "I don't recognize this" reports, Fleet compliance loss and Shared Signals events; Security → Identity Threat Protection decides automated responses (notify, re-MFA, terminate the session, Universal Logout, suspend) and how long risk lasts.