Access Risk

The Risk Based Authentication (RBA) module retrieves real-time information about the user who is authenticating or authorized to access an application. It uses them to:

• assess the risk score of the requested access

• restrict the list of possible authentication mechanisms that allow the user to access the application.

The goals of the RBA module are to:

• Compute the risk score that corresponds to the probability that a user may not be legitimate when they are authenticating. The risk score is between 0 and 100. 0 means that there is no risk and 100 that the risk is extremely high.

• Select the authentication mechanisms to offer to the user when they are authenticating.

• Define if the user can access the application they want to after their authentication. An authorization request can occur several days after the above authentication step, if the user's SSO session is still active, and it may target an application different from the one targeted during the authentication step

  • if the RBA grants access, the user can transparently access the application

  • if the RBA denies access, the RBA returns the authentication mechanisms available for a step-up

Configuration order

Prerequisite

• Configure authentication mechanisms.

• Request the RBA module activation to Memority Professional Services.

You must configure the RBA objects in a specific order. Each step relies on data computed in the previous one:

To configure the policies, you must add condition rules written in groovy scripts. To know more, see RBA Rule definition.

Steps of a Risk-Based Authentication

When an identity tries to access an application, the RBA module applies several policies to determine the access risk and required authentication level:

• Environment Risk Policy: The system evaluates the risk based on the device (new location, device inactivity, etc.).

• User Risk Policies: The system updates the risk based on the user’s behavior (unusual login time, location change, etc.).

• Authentication Risk Policies: Based on the current risk score, the system suggests authentication mechanisms compatible with the following requirements:

  • a maximum acceptable risk

  • a minimum authentication level.

The user must then choose an authentication mechanism among the possible ones.

Step 0: The user initiates a connection request to the target application.

Step 1: The RBA evaluates the connection request based on all the rules of the Environment Risk Policy. At the end of the evaluation, the system establishes a Partial Risk Score (PRS) based on the Environment Risk Policy for this connection request.

Step 2: The User Risk Policy updates the PRS based on the user’s previous activity and how it matches their current connection request. After the evaluation of all the rules in the User Risk Policy, the system establishes a Risk Score for this connection request.

Step 3: The RBA runs the Authentication Risk Policy to suggest an authentication mechanism for this request. For each mechanism it will evaluate the following criteria:

If the Risk Score - Risk Correction ≤ Maximum Acceptable Risk (as defined in the Authentication Risk Policy) and the Authentication Level ≤ Maximum Authentication Level (also defined in the Authentication Risk Policy), the system accepts the mechanism.

Step 4: On the login page, the user sees the accepted authentication mechanisms. To finalize the connection request and connect to the target application, the user will select one of the suggested authentication mechanisms and proceed with the authentication.

Access Risk Corrections

Authentication mechanisms are not all equal in terms of security.

There are two values taken into account for each authentication mechanism:

• Authentication level. This value defines the strength of the authentication mechanism.

• Risk correction. This value defines how much the authentication mechanism reduces the estimated risk.

Examples:

• Password-only authentication is a weak authentication mechanism. As a result, it has an authentication level of 10 and provides a risk correction of 5.

• Multi-factor authentication is a strong authentication mechanism. As a result, it has an authentication level of 100 and provides a risk correction of 50.

Evaluating the Risk Score

When the system evaluates a login attempt, it computes an initial risk score based on contextual factors (such as location, device, or network), applying Environment and User Risk Policies. Then, it constitutes the list of usable authentication mechanisms, applying Authentication Risk Policies.

Final Risk Score = Risk Score – Risk Correction of the authentication mechanism

Condition 1: Final Risk Score must be ≤ Maximum Acceptable Risk (for example, 15)
Condition 2: Authentication Level of the mechanism must be ≥ Minimum Authentication Level (for example, 20).

If both conditions are met, the authentication mechanism is deemed eligible and is proposed to the user. Otherwise, the system rejects the mechanism and requires a stronger one.

User scenario example

An identity wants to connect to a Memority federated application with the correct login and password. Usually, the identity connects from Paris, France, but this time, the identity tries to connect from Belgium.

Check the Environment Risk Policy

What does the identity do?

The identity tries to connect to a Memority federated application from a device they have not used for 30 days or more.

What does the system do?

The system applies the environment risk policy and the following rule: The device has not been used for more than 30 days.

The system increases the risk score with 10.

<kit:DataSet xmlns:kit="http://www.memority.com/toolkit/1_0" xmlns:riskrba="http://www.memority.com/risk/rba/1_0" xmlns:rule="http://www.memority.com/toolkit/rule/1_0" xmlns:search="http://www.memority.com/toolkit/search-expression/1_0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tenant="memority" env="embedded,test,no-dev">
   <riskrba:EnvironmentRiskPolicy>
      <riskRules>
         <riskRule>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[
                 // Device not used since 30 days
DYN.device.lastAuthenticationInterval >= 30]]></script>
            </matchingCondition>
            <name>ENV-RR-DEV-1</name>
            <riskCorrection>10</riskCorrection>
         </riskRule>
      </riskRules>
   </riskrba:EnvironmentRiskPolicy>
</kit:DataSet>

To know more, see Environment Risk Policy.

Check User Risk Policies

What does the identity do?

• The identity enters their login.

• They try to connect from Belgium.

What does the system do?

• The system has access to the identity history.

• It applies the user risk policy and its rules.

• It identifies that the identity last authentication was from Paris and the current one is from Belgium.

• It increases the risk score by 50. The risk score is now of 60.

At this step

Risk score = Environment Risk score + User Risk score

Risk score = 10 + 50

Risk score = 60

<kit:DataSet xmlns:kit="http://www.memority.com/toolkit/1_0" xmlns:riskrba="http://www.memority.com/risk/rba/1_0" xmlns:rule="http://www.memority.com/toolkit/rule/1_0" xmlns:ruleaddon="http://www.memority.com/toolkit/addons/rule/1_0" xmlns:search="http://www.memority.com/toolkit/search-expression/1_0" xmlns:settings="http://www.memority.com/toolkit/addons/settings/1_0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tenant="danube">
   <riskrba:UserRiskPolicy id="common-userRiskPolicy">
      <name>Common User Risk Policy</name>
      <description>Common user risk policy for all users.</description>
      <riskRules>
         <riskRule>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[
                 // Assess if user authenticates during the night
                 LocalTime lt = DYN.location.localTime
LOG.debug("USER-RR-MOM-1 - DYN.location.localTime - {}", DYN.location.localTime)
LOG.debug("USER-RR-MOM-1 - LocalTime.of(22, 0) - {}", LocalTime.of(22, 0))
LOG.debug("USER-RR-MOM-1 - lt.isAfter(LocalTime.of(22, 0)) - {}", lt.isAfter(LocalTime.of(22, 0)))
lt.isAfter(LocalTime.of(22, 0)) || lt.isBefore(LocalTime.of(06, 0))]]></script>
            </matchingCondition>
            <name>USER-RR-MOM-1</name>
            <riskCorrection>20</riskCorrection>
         </riskRule>
         <riskRule>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[
                 // User authenticated too much distance from last authentication
LOG.debug("USER-RR-LOC-2 - DYN.user.lastLocationDistance {}", DYN.user.lastLocationDistance > 100)
LOG.debug("USER-RR-LOC-2 - DYN.user.lastLocationVelocity {}", DYN.user.lastLocationVelocity > 10)

DYN.user.lastLocationDistance > 100 && DYN.user.lastLocationVelocity > 10]]></script>
            </matchingCondition>
            <name>USER-RR-LOC-2</name>
            <riskCorrection>50</riskCorrection>
         </riskRule>
      </riskRules>
      <matchingCondition>
         <script><![CDATA[return true]]></script>
      </matchingCondition>
   </riskrba:UserRiskPolicy>
</kit:DataSet>

To know more, see User Risk Policies.

Check Authentication Risk Policies

During this step, the system checks the above risk score against thresholds configured on the Authentication Risk Policy.

• Maximum Acceptable Risk = 15

• Minimum Authentication Level (MAL) = 0

The system tests each available authentication mechanism:

1. Password-only

• Residual risk = 60 – 5 = 55

• 55 is higher than the maximum acceptable risk of 15 → rejected

• Authentication level = 10, which is higher than MAL = 0, but the risk is still too high

2. Multi-factor authentication (MFA)

• Residual risk = 60 – 50 = 10

• 10 is lower than the Maximum Acceptable Risk of 15 and higher than the Minimum Authentication Level → accepted

• Authentication level = 100, which is higher than MAL = 0

As a result, the system rejects the password-only option and suggests the MFA to the user, which is the authentication mechanism below the Maximum Acceptable Risk (15) and higher than the Minimum Authentication Level.

<kit:DataSet xmlns:kit="http://www.memority.com/toolkit/1_0" xmlns:riskrba="http://www.memority.com/risk/rba/1_0" xmlns:rule="http://www.memority.com/toolkit/rule/1_0" xmlns:ruleaddon="http://www.memority.com/toolkit/addons/rule/1_0" xmlns:search="http://www.memority.com/toolkit/search-expression/1_0" xmlns:settings="http://www.memority.com/toolkit/addons/settings/1_0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" tenant="danube">
   <riskrba:AuthenticationRiskPolicy id="usrPortal-authenticationRiskPolicy">
      <name>Sensible Apps Authentication Policy</name>
      <description>Authentication Policy for sensible applications</description>
      <evaluationPriority>50</evaluationPriority>
      <matchingCondition>
         <script><![CDATA[
           // Sensible applications have a low risk tolerance
          return APP.riskTolerance < 25
]]>
         </script>
      </matchingCondition>
      <maximumAcceptableRisk>15</maximumAcceptableRisk>
      <authenticationRules>
         <authenticationRule>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[return APP.name.contains('PeopleDoc')]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>70</minimumAuthenticationLevel>
            <name>RR-APP-1</name>
         </authenticationRule>
         <authenticationRule>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[return APP.name.contains('Accounting')]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>80</minimumAuthenticationLevel>
            <name>RR-APP-1</name>
         </authenticationRule>
      </authenticationRules>
   </riskrba:AuthenticationRiskPolicy>
</kit:DataSet>

To know more, see Authentication Risk Policies.