Conditional access policy

Introduction

This page describes how to write a conditional access policy script for an OTP authentication connection. When a user is required to register a second factor method such as TOTP Authenticator, WebAuthn, or OS2faktor, Identify checks if the user is allowed to do so by evaluating the conditional access policy script. This feature gives you the power to control the conditions in which your users can register their second factor methods and log on. As a result, you can ensure that the right user, not an attacker, is doing registration.

Where to write the conditional access policy script

You can write a conditional access policy script for an OTP authentication connection by going to the Conditional access tab:

conditional-access-policy-script

You can find all syntax and built-in functions here

The order of rules is important. If one rule is not satisfied or returns false, all later rules are ignored. An empty script means no conditional access applies.

When a user is not allowed to register a second factor method due to the conditional access policy, Identify displays an error page:

login-blocked-page

and provides the Return to login selector page option where the user can select another login method (if there is any).

You can customize the above error page by using its hosted form:

login-blocked-page-hosted-form

Common cases

  1. Allow the conditional access for an IP address range and forbid another IP address range.
Rules
    .ApplyIPAddressRange("192.168.1.1 - 192.168.1.20")
    .NotApplyIPAddressRange("192.168.1.17 - 192.168.1.18");

The most common usage is to allow users to register from a trusted intranet only.

  1. Enable registration only when users are coming from a specific service provider:
Rules.ApplyExpression((RuleContext) => {
    return RuleContext.ProtocolConnectionEntityId == "ServiceProvider1";
    });
  1. When users have a specific claim

Please note that if the first factor is a Username & password connection, then at the registration time all user claims with the exception of the username claim will not have been loaded yet (they are loaded at the Claims Transformations step). This use case is more useful when the first factor is an upstream Identity Provider.

Rules
    .ApplyExpression((RuleContext) => {
        return RuleContext.FirstFactorPrincipal.HasClaim("urn:identify:rest-api:role", "Administrator");
    });

If the first factor is a Username & password connection, the rule above will always return false.