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 and Authentication Context References

An Authentication Flow determines the authentication flow you want to use for each risk level in the resource rule. An Authentication Context Resource (ACR) is used by SAML and OIDC Identity Providers to set the type of authentication that should take place to allow access. IDaaS provides a number of system authentications flows and ACRs, but you can additionally create customs ones to meet your needs.

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 enabled then the user is denied access even if other resource rules allow access.

● If Enable Strict Access 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 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.

– Limitations

– Resource rules for RADIUS applications only include the Date / Time, Geolocation and Source IP Address condition restriction.

– The Authentication Decision steps that you can select for a RADIUS application resource rule depend on whether the RADIUS application uses EAP RADIUS authentication.

– If the settings of a RADIUS application on Identity as a Service are modified so that the application uses EAP RADIUS authentication, or the type of EAP protocol used is changed, the resource rule associated with the RADIUS application is automatically updated.

– RADIUS applications with no EAP support the following second-factor authenticators: knowledge-based authentication, temporary access code, one-time password, grid, hardware/software token, token push, and smart credential push.

– RADIUS applications with RADIUS MSCHAPv2 support only temporary access code and hardware/software token second-factor authenticators.

– When creating a resource rule for a RADIUS application, you can select EXTERNAL+no second-factor.

– RADIUS applications with RADIUS GTC support the following second-factor authenticators: software/hardware token, one time password, grid, temporary access code, knowledge-based authentication.

– 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 be used with these applications.

– When configuring a resource rule for the Entrust IdentityGuard Desktop application, the user ID has to match the user ID in the domain controller.

– Authentication API applications support Transaction Contexts. See the sections Transaction Items and Set Transaction Rules in Modify risk-based authentication general settings.

● Edit User Portal resource rule placeholder is added to configure step-up authentication rules to allow a user to edit their user profile.

● If in a release prior to 5.36 you had configured step-up authentication, an Edit User Portal resource rule has been automatically added to your IDaaS tenant with an authentication flow of Skip Password and OTP only for second-factor authentication. You can edit this resource rule to meet your needs.

● Once you create the resource rule, it is enabled automatically for step-up authentication.

Protect applications with resource rules

Authentication Flows and Authentication Context References

Authentication Decisions

Multiple resource rules

Types of resource rules

Resource rule limitations