Access policies: how they work

The access policy decides which application sign-ins and which operation approvals are allowed in your organization. It is a document of rules with immutable revisions.

The most important rule

Without an active revision, everything the policy controls is refused. The console says: «ProofFlow denies by default while there is no active revision.» Application sign-ins end with access_denied (OIDC) or RequestDenied (SAML).

What does the policy control?

• Application sign-ins: OIDC services, SAML applications and Microsoft 365 (action federation.authorize).
• ProofFlow operation approvals.
• Windows sign-ins (authguard.desktop, actions desktop.logon, desktop.unlock, desktop.rdp, desktop.elevate).
• Privileged access requests (actions pam.checkout, pam.session, pam.jit).

It does not control signing in to the console itself, nor phone approvals of sign-ins and administrative confirmations.

How is it organized?

Under «Manage» › «Policy» › «Access policy» you see three positions:

Each revision is immutable: «Once created, a revision cannot be changed or deleted.» To change, you create a new revision.

What does a rule look like?

Each rule has an id, a priority, an effect (allow, deny or step_up) and an all_of list of conditions that must all match. Available conditions include action, audience, resource, authentication method, local verification, freshness, groups, roles, network zone, country, schedules and device state. Up to 256 rules and 32 conditions per rule.

How do I change it safely?

• Quick path: «Create and activate» (one approval). See Create and activate a revision.
• Careful path: create, stage as candidate, simulate, promote. See Simulate a policy.

Each transition fails if another administrator changed the policy meanwhile. If something goes wrong, «Roll back active» returns to the previous revision.