# Authentication Rules - Link: https://www.agilicus.com/anyx-guide/authentication-rules/ - Published: 2024-05-14T00:24:32+00:00 - Author: Don Bowman 1. [Home](https://www.agilicus.com/) 2. Authentication Rules ![Agilicus ANYX Authentication Rules Guide - Secure Access Control for Cloud Resources. Learn how to implement robust authentication policies with Agilicus ANYX. Explore books on cloud security and access management. Image: Books on a shelf representing knowledge and learning.](https://www.agilicus.com/www/52f05c70-books.png) Multi-factor, geography, per-app --- ## Authentication Rules Authentication Rules are a type of Conditional Access. They are logically part of the authentication flow, after the user has proven identity. [CONTACT](https://www.agilicus.com/contact-us/) ## Authentication Rules Authentication Rules are a type of Conditional Access. They are logically part of the authentication flow, after the user has proven identity. These rules can augment the logic with things like: * has provided multi-factor authentication * is in / not in IP ranges * application properties * user properties * device properties The system has a set of policy presets. These operate like macros, overriding the current rules and then leaving them free to configure. ## Theory of Operation The Authentication Rules are a set of Conditions (things we measure) and Actions( things we do). ### Conditions Conditions include any field in any Object in the system. The generic Object types include: * User * (Application) Client * Issuer * Login Session #### Details * Clients.application == name of the Authentication Client * Clients.id == ID of the Authentication Client * Clients.issuer_id * Clients.mfa_challenge * Clients.single_sign_on * Clients.name * Clients.org_id * Clients.organisation_scope * Clients.secret * User.id * User.external_id * User.enabled * User.status * User.first_name * User.last_name * User.email * User.provider * User.org_id * User.type * User.created * User.updated * User.auto_created * User.member_of.external_id * User.member_of.enabled * User.member_of.status * User.member_of.first_name * User.member_of.last_name * User.member_of.email * Issuers.id * Issuers.issuer * Issuers.org_id * Issuers.upstream_redirect_uri * Users.multi-factor_challenge_type * Login.session.number_of_logins * Login.session.number_of_failed_multi_factor * Login.session.single_sign_on_time * Login.session.user_is_authentication * Login.session.user_is_authenticated_by_upstream * Login.session.user_is_authenticated_by_cache ## Presets ### Default You should choose this option for strong security and convenience for your users. Using a single identity source of truth among many applications enables maximal ease of use, while enabling multi-factor-authentication ensures that anyone without physical access to their device(s) cannot compromise the account. You will always be able to revoke a user’s access at any time and audit their usage of any applications or services. Details: Multi-factor authentication can be enabled per client, by default it will follow a user’s preference A user’s session is shared between apps unless that app’s client has Single Sign-On set to ‘never’ A user’s session lasts up to 7 days Multi factor authentication must be used to log in after every 30 days if a multi-factor authentication method has been configured ### Permissive You should choose this option if the data you need to get to your employees needs to be protected, but is not of a particularly sensitive nature. This option enables low barrier to entry to get as many users as possible onto the system with as little administrative overhead as possible. You will always be able to revoke a user’s access at any time and audit their usage of any applications or services. Details: Multi-factor authentication can be enabled per client, by default it will follow a user’s preference. A user’s session is shared between apps unless that app’s client has Single Sign-On set to ‘never’ A user’s session lasts up to 14 days Multi factor authentication must be used to log in after every 30 days if enabled ### Strict You should choose this option if you need the minimum ‘blast’ radius from a compromised device. By reducing the sharing of sessions between applications, minimizing multi- factor authentication duration and requiring frequent logins you can guarantee that in the event an employee’s device is compromised they cannot access anything other than what the employee is currently logged into. You will always be able to revoke a user’s access at any time and audit their usage of any applications or services. Details: Multi-factor authentication can be enabled per client, by default it will follow a user’s preference A user’s session is not shared between apps unless that app’s client has Single Sign-On set to ‘always’ A user’s session lasts at most 1 day Multi factor authentication must be used to log in every 7 days ## Example Authentication Policy Below is the expanded ‘strict’ example, applied to an organisation with solely Time- Based One Time. First, groups. Rules in a group are evaluated until a match occurs. All groups are evaluated. In this example, our first group is called ‘default authentication rules’. Inside it, the first rule: “If Login.session.user_is_authenticated == False then Authenticate” forces the user to get credentials. Next, we disable single-sign-on and caching for strong-authentication clients, this forces the user to provide credentials each time to these sensitive apps. “If Clients.single_sign_on == never && Login.session.user_is_authenticated_by_cache then Authenticate” Now we check for > 1 day old (86400 s) cached credentials, and disallow “If Login.session.single_sign_on_time > 86400 && Login.session.user_is_authenticated_by_cache then Authenticate” Now, for any authentication client which forces a 2nd factor: “If Clients.mfa_challenge == Always then Require 2nd Factor” “If User.multi-factor.challenge_type in totp then Require 2nd Factor” [⌊d2724907-image⌉⌊d2724907-image⌉[ [⌊03a001c7-image⌉⌊03a001c7-image⌉[ [⌊0fbea856-image⌉⌊0fbea856-image⌉[ [⌊eba74c13-image⌉⌊eba74c13-image⌉[ ![360e 4225 ad0d 891d6dbbdd02](blob:https://www.agilicus.com/3589b9c8-360e-4225- ad0d-891d6dbbdd02) ## JSON API Example The above ‘strict’ example looks as below in the API: ```javascript { "default_action": "deny_login", "issuer_id": "no_issuer", "name": "strict", "org_id": "no_org", "policy_groups": [ { "metadata": { "id": "no_id" }, "spec": { "name": "default authentication rules", "rule_ids": [ "1", "2", "3" ] } }, { "metadata": { "id": "no_id" }, "spec": { "name": "default multi-factor authentication rules", "rule_ids": [ "4", "7", "5" ] } }, { "metadata": { "id": "no_id" }, "spec": { "name": "default allow rules", "rule_ids": [ "6" ] } } ], "rules": [ { "metadata": { "id": "4" }, "spec": { "action": "allow_login", "conditions": [ { "condition_type": "type_last_successful_mfa", "input_is_list": false, "inverted": false, "operator": "less_than", "value": "604800" } ], "name": "User has successfully provided a second factor within time window", "org_id": "no_org", "priority": 1 } }, { "metadata": { "id": "6" }, "spec": { "action": "allow_login", "conditions": [ { "condition_type": "type_object_attribute", "field": "login_session.user_is_authenticated", "input_is_list": false, "inverted": false, "operator": "equals", "value": "true" } ], "name": "User is authenticated", "org_id": "no_org", "priority": 1 } }, { "metadata": { "id": "2" }, "spec": { "action": "authenticate", "conditions": [ { "condition_type": "type_object_attribute", "field": "clients.single_sign_on", "input_is_list": false, "inverted": false, "operator": "equals", "value": "\"never\"" }, { "condition_type": "type_object_attribute", "field": "login_session.user_is_authenticated_by_cache", "input_is_list": false, "inverted": false, "operator": "equals", "value": "true" } ], "name": "Single Sign-On is not allowed for specified clients", "org_id": "no_org", "priority": 1 } }, { "metadata": { "id": "1" }, "spec": { "action": "authenticate", "conditions": [ { "condition_type": "type_object_attribute", "field": "login_session.single_sign_on_time", "input_is_list": false, "inverted": false, "operator": "greater_than", "value": "86400" }, { "condition_type": "type_object_attribute", "field": "login_session.user_is_authenticated_by_cache", "input_is_list": false, "inverted": false, "operator": "equals", "value": "true" } ], "name": "User has successfully authenticated within the time window", "org_id": "no_org", "priority": 1 } }, { "metadata": { "id": "3" }, "spec": { "action": "authenticate", "conditions": [ { "condition_type": "type_object_attribute", "field": "login_session.user_is_authenticated", "input_is_list": false, "inverted": false, "operator": "equals", "value": "false" } ], "name": "User is unauthenticated", "org_id": "no_org", "priority": 1 } }, { "metadata": { "id": "5" }, "spec": { "action": "do_mfa", "conditions": [ { "condition_type": "type_object_attribute", "field": "user_mfa_preferences.spec.challenge_type", "input_is_list": true, "inverted": false, "operator": "in", "value": "[\"totp\"]" } ], "name": "User has registered Multi-Factor Authentication", "org_id": "no_org", "priority": 1 } }, { "metadata": { "id": "7" }, "spec": { "action": "do_mfa", "conditions": [ { "condition_type": "type_object_attribute", "field": "clients.mfa_challenge", "input_is_list": false, "operator": "equals", "value": "\"always\"" } ], "name": "User has registered Multi-Factor Authentication", "org_id": "no_org", "priority": 1 } } ], "source": "default-catalogue", "supported_mfa_methods": [ "totp" ] } ``` ## Authentication Session Authentication sessions identify users to Agilicus automatically so that they need not log in every time they try to access the system. This session is tied to a given browser/device. When users accesses the system from a new browser, or a new device, they will be prompted to log in. If their session has expired, users will be prompted to re-authenticate. A session expires according to the authentication policy rule which controls its lifetime. The rule, expressed in seconds, constrains for how long the session is valid. ![image](https://www.agilicus.com/www/1787c801-image-1024x487.png) For the policy shown in above screenshot, session is valid for 1209600 seconds, or 14 days. Users will be required to reauthenticate every 14 days. This particular rule fires for users who have authenticated, but whose session was created more than 1209600 seconds ago. The action is Authenticate, meaning that when the rule matches, users are forced to authenticate. ### Configuring Maximum Session Duration To configure the maximum session duration, either apply a new preset, or edit the“ User has successfully authenticated” rule’s “login session single sign on time” condition. For the preset, configure the “Sessions valid for” field. ![image](https://www.agilicus.com/www/768a9ab9-image-1024x487.png) For the existing rule, choose “configure condition”. ![image](https://www.agilicus.com/www/5cb76bcd-image-1024x487.png) Then edit the value in the “Configure condition details” section. Do not change its operator. ![image](https://www.agilicus.com/www/74b64082-image-1024x487.png) Note that the minimum effective value is 86400 seconds, or one day.