Create and manage resource rules

Resource rules protect applications by setting access restrictions. When a user attempts to authenticate to an application, the resource rule determines a user's risk level by using a series of security tests to generate a risk score. Based on the circumstances under which a user is authenticating to an application (such as their location, machine authenticator information, and date and time), and the restrictions set in the resource rule, the user is granted or denied access to the application.

The risk-based authentication (RBA) settings of a resource rule define how a resource rule responds to users who are classified as Low Risk, Medium Risk, or High Risk. The number of risk factors set determine the number of risk points assessed to users restricted by the resource rule, as follows:

● If a resource rule only contains one risk factor, and that condition's RBA test fails, the user is deemed high risk.

● If a resource rule contains no risk factor, then the authentication flow defined for a Low Risk level always applies.

● If a resource rule contains more than one condition, it will calculate the total risk percentage to determine low, medium, or high risk.

For example, if a resource rule contained two active conditions (one set to 80% and the other set to 20%) and the condition set to 80% failed, the risk formula would be: 80/100=80%.The percentage resulting from the formula is used to classify the user as low, medium, or high risk.

● By default, the risk levels are set in the Risk-Based Authentication (RBA) settings (see Manage risk-based authentication settings). You can also modify the Medium and High risk points in the General Settings of the Resource Rules List page.

Authentication Flows

To create a resource rule, you also need to determine the authentication flow you want to use for each risk level in the resource rule. See Create authentication flows.

Transaction contexts

Resource rules can support up to two transaction contexts as part of their evaluations for Entrust Identity as a Service Authentication API applications. Transaction contexts work as follows:

● Resource rules can support up to two transaction contexts as part of their evaluations for Entrust Identity as a Service Authentication API applications. Transaction contexts work as follows:

● A transaction context is associated with one or more transaction rules with a risk score. As transaction rules are evaluated, if the accumulated risk score of the failed transaction rule is greater than a defined risk limit value for the transaction context, risk is assumed and the transaction context risk points are added to the overall risk point total.

● A transaction rule expression is a boolean expression, using AND and OR operators, where the operands of the expression can be additional transaction rule expressions or transaction item expressions.

● A transaction item expression is a simple, single expression of a transaction item and its expected value (for example, Account = "S053541", Amount > "10000", Action = "DEPOSIT", Channel = "ATM").

● A transaction item is a transaction detail name, that is passed in transaction details during authentication, along with its type (STRING or NUMERIC), whether it must be present if a transaction rule uses it, and its default value if it is does not need to be present and is not passed as part of the transaction details during authentication.

Authentication Decisions

Based on the risk score, the resource rule makes an Authentication Decision to determine the authentication flows allowed to access the application. A user might also be denied access to the application if the risk score exceeds the acceptable level set by the resource rule.

If you enable the User Login flow, you must configure first-factor and Second Factors settings. These settings allow administrators to clearly define the authenticators users are prompted to use when they authenticate to an application.

● The selected first-factor authenticator defines the list of authenticators included in the Second Factors list.

– If Skip Password is set, the user is prompted to respond to a second-factor authenticator without providing a password.

– If Password is set, the user must first enter their password and then respond to a second-factor challenge.

– If External Authentication is set with Bypass second-factor authentication if user does not exist selected, low risk users who do not exist in Identity as a Service can log in without second-factor authentication. If users already exist in Identity as a Service, they must still perform second-factor authentication regardless of the bypass setting.

Note: External authentication must apply to all groups and is available only for Authentication APIs and RADIUS applications that support external authentication. If External Authentication does not include the bypass second-factor option, you must select the second-factor authenticators.

– Only selected authenticators in that list can be used to complete a second factor authentication challenge.

– During authentication, the resource rule prompts the user to complete the first-factor authenticator set for the risk level.

– Once the user completes the first-factor challenge, the user is prompted with the most preferred second-factor authentication challenge. If a user does not have a specific authenticator, they are prompted to log in using the next-most preferred authenticator on the list.

For example, if Entrust Soft Token appears at the top of the list of second-factor authenticators, the user is prompted to authenticate using Entrust Soft Token. If the user does not have an Entrust Soft Token, the user is prompted to authenticate using the next second-factor authenticator in the list, and so on.

● If your account has been set up to allow Smart Login and your authentication flow has the Smart Login flow enabled, you can set the resource rule to allow Smart Card Login.

– When enabled, a user with a Mobile Smart Credential paired to your account can authenticate to your Identity as a Service account (User or Admin Portal) or a SAML or OIDC and OAuth application integrated with Identity as a Service without the need to provide a user name and password or respond to the challenges set up in the resource rule.

– This feature is only available if your account has been set up to allow Smart Login. Contact Entrust if you do not have this feature enabled and would like to use Smart Login.

Note: Smart Login can be used only to access the Identity as a Service Admin Portal, User Portal, and SAML and OIDC applications integrated with Identity as a Service.

● If you enable the Smart Login, Passkey, or Identity Provider flow, when a user first accesses the IDaaS portal, all the enabled options are available on the page because during the initial login, the user ID is unknown and therefore, the authentication flow that applies to the user based on the resource rule risk level has not yet been determined.

For example, if the user selects the Passkey flow and the user has a passkey token registered, the user could be denied access because once the user ID is obtained from the token, the resource rule evaluation might select an authentication flow that does not allow using Passkey.

Multiple resource rules

If an application has multiple resource rules, Identity as a Service selects the resource rule to be used as follows:

● If any resource rule denies access and has Enable Strict Access for Application enabled then the user is denied access even if other resource rules allow access.

● If Enable Strict Access for Application is disabled (false), and if one or more resource rules allows access then the user is allowed access.

Example: An application has a resource rule that applies to all users and allows access. A trial is set up for a small group of users to restrict access to that application. This is done by adding those users to a group and creating a resource rule for that group that restricts access to the application. However, it turns out that the users in the trial are still allowed access because they also have access using the default resource rule.

When Enable Strict Access for Application is enabled for the resource rule for the trial group, all users in the trial group are denied access if the trial resource rule denies access even if the default resource rule allows access.

Types of resource rules

Application resource rules define the authentication requirements to access an application configured for Identity as a Service authentication.

Resource rules for the Identity as a Service portal define the authentication level required to access an Identity as a Service account. Identity as a Service accounts have two system-defined resource rules for the Identity as a Service portal that cannot be deleted.

Table: System-defined resource rules

Rule name	Resource	Description
User Portal - All Users	User Portal	Enables users without a role to authenticate to the User portal of their account
Administration Portal - Administrators	Entrust Identity as a Service Administration	Enables users with an administrator role to authenticate to the Administrator portal of their account. See Create and assign roles for more information.

Resource rule limitations

The type of application that a resource rule protects determines the restrictions for the resource rule as follows:

Resource rules for SAML and OIDC applications cannot have resource rules with External Authentication set as the First Authentication Step.

– Identity Provider, and Smart Login flows cannot be used for RADIUS application resource rules.

– Resource rules for Entrust IdentityGuard applications only include the Date / Time condition restriction.

– The Entrust Soft Token Push, Software/Hardware Token, One Time Password system authentication flow can used with Low Risk.

– This authentication flow can be cloned and you can enable or disable as required additional authenticators as required.

– Only Knowledge-based Authentication, Temporary Access Code and GRID can also be used with these applications.