Menu AuthGuardHelp centre
Portuguêsauthguard.pt

Tutorial 06 · 2:24

Access policies

Publish the policy that decides who signs in to each application, test it before activating and roll back safely.

Tutorial 06Access policies2:24 · Narrated in Portuguese, with English captions.

Download the video (MP4)

Transcript

In this tutorial, we publish the access policy: the rules that decide who signs in to each application, which operations can be approved, and who requests privileged access. The most important rule: without an active revision, everything the policy controls is refused. Application sign-ins, operation approvals, Windows and privileged access. Signing in to the console itself doesn't depend on the policy.

Under Manage, Policy, you see three positions: the active revision, which decides; the candidate, evaluated in shadow, with no effect; and the previous one, to roll back to. Every revision is immutable: to change, you create a new one. Each rule has a priority, an effect, allow, deny or step up, and conditions that must all match: the action, the application, the authentication method, groups, the network zone or the schedule.

To create one, choose New revision and write the document. For example, a rule that allows the applications to anyone who signs in with a passkey or the phone. Choose Review revision and check the rules. The change asks for an approval: on the phone or with your passkey. The phone shows the action, the revision and the digest. Approve only if they match what you mean to change.

The approval works once, only for this command. For risky changes, take the safest path: create the revision without activating it, prepare it as the candidate, and use Test decision with sample contexts. The result is advisory only. When you're confident, promote the candidate. Network zones classify each connection by the address the server sees.

Declare the company network, and use the zone in a rule: for example, accept the phone inside the company, and require a passkey outside it. If something goes wrong, Roll back active returns to the previous revision, also with an approval. And if another administrator changes the policy meanwhile, nothing is applied: refresh and repeat. And that's it: clear rules, immutable revisions, and every change approved.

In the next tutorial, we'll connect applications through OpenID Connect and SAML.