Risk-based Authentication

Each resource protected by DirX Access can be paired with any number of risk conditions. When requesting this resource, the RBA evaluation is employed. At the highest level of abstraction, it is a simple comparison of two numbers: assurance level and risk level.

The assurance level is a number that is relevant to each user. It is the highest assurance level among the authentication methods that the user successfully used in the current interaction (session) with the DirX Access-protected system, so it is user-dependent.

The risk level is the sum of the risk condition evaluations relevant to the currently requested resource, so it is both user- and request-dependent.

The risk-based evaluation takes place in the processing of each request, as shown in the Figure 1

In the case of an authorization request during an active session, there is no need for a credentials check. However, the RBA evaluation is still employed. If the RBA policies are violated, the user is required to reauthenticate. He is informed about this action by an explicit prompt and the event is audited (code: DXA850AN321E).

Compared to the general risk conditions, the user-context-aware conditions represent a much more powerful mechanism. This mechanism depends strongly on the user behavior, which enforces the collection and storage of the relevant data for each user separately. In addition, the risk level estimation cannot be as easily foreseen as in the case of general risk conditions.

The risk level returned by a user-context-aware condition is a floating point number from the interval <0; [defined_risk_level]>.

The usage of user-context-aware conditions extends the RBA evaluation process from the initial diagram shown in Figure 1 to the diagram shown in Figure 3.

The request data are evaluated against the data collected during the history of user-system interaction – user model. The data collected during the active session becomes relevant in the next session. In the case of a successful evaluation, request data are included into a new user model, following the rules set by the configuration of RBA data collectors. When the session ends, the new user model is propagated from the temporary storage to a persistent one (the new user model becomes a historical one).

From the operations upon persistent repository perspective, there are two processes: data loading during the session creation (read operation), and data persisting during the session destroy (read + write operation).

DirX Access uses its Application Repository to store the risk-based authentication data. The RBA data collector configuration enables the complete control of the spatial needs of the data. Moreover, there is a trade-off between the amount of data stored and the accuracy of the evaluation result.

For each user, the maximal spatial complexity can be computed as a sum of the maximal spatial complexities of all defined RBA data collectors. The maximal spatial complexity of an RBA data collector is defined as:

[No. of periods]*([Max no. of collected values]*[Max value length] + 7) + C

where the first two items are parameters of the RBA data collector, the third item is to be learned from a context, and C is maximally in the order of tens.

On the other hand, we want the data collecting to mirror the real situation as much as possible - we need the data to age reasonably and we have two possibilities for how to achieve it. First, the period mechanism claiming: any younger period has a bigger impact on the evaluation result than the older one. In this way, we can appropriately set up the interval of interest and divide it into periods (number of periods parameter) of meaningful lengths (sampling period length parameter). For example, in the case of access times, we are interested in the last six months and want to handle the data from (approximately) a single month on the same level. Thus, we have the following settings: number of periods = 6, sampling period length = 30.

Note: the period does not have a floating character (user relative) - it is an interval with an absolute position within time and thus is the same throughout the system. The absolute position of any period depends solely on the sampling period length parameter determining the position of any period throughout the history.

Of course such an approach can be quite demanding for some deployments. To lessen the amount of data stored, we can decrease the number of periods (while increasing their lengths to preserve the same interval of interest). To enable the data to age in this situation, we can set up max value weight. It influences the system in the following manner: once any record has occurred during a single period [max value weight]-times, all the weights (numbers of occurrences) of all records are divided by two. With this method, the data age in a logarithmic-based manner.

It is worth mentioning that the estimated spatial complexity is likely to differ substantially from the maximal one. It may also depend on the sampling period length, as it is often improbable that the maximum number of collected values is reached.

Users of each system behave differently, so it is difficult to approximate the combined effect of various risk conditions. There is also the possibility that some systems will have users with such an irregular behavior that it can’t be modelled (hence evaluated) with some of the conditions.

To configure a user-context-aware risk condition properly, DirX Access provides the evaluation test mode switch that enables evaluation of the particular risk condition without including its result into the overall risk level. The results can be monitored using MBeans and should be analyzed in order to optimize the risk condition configuration.

The main analysis of the received data should address the probability distribution of the outcomes. Let us assume that almost all the data are collected from legitimate requests. With respect to this assumption, we want most of the data to have a negligible risk level, while the rest having the highest risk level (when a new behavioral pattern occurs). The more the real distribution comes closer to the one described, the more this configuration of risk condition is applicable.

The analysis can be performed using the PolicyServiceMonitorMXBean.

For some cases it might be desirable to limit the data saved about the user, particularly RBA data used in User-Context-Aware Risk Conditions. The reason for this might be to comply with data protection regulations such as GDPR, which mandates limiting the collection of personal data, or to reduce the amount of data stored in the Application Repository. The Cluster can be set in a way that no RBA data are collected unless the user provides consent.

To enable this, set the Require user data consent parameter in Cluster → Authentication Service to true. By default, no user consent is required, but when this parameter is set to true, RBA data will not be collected or saved unless the user provides consent. The user can provide consent by setting the userDataConsent property of his AppRepoEntity to true. This can be done through the SCIM API or through the Credential Manager.

Setting the flag Just-in-time provisioning of user record to AppRepo to false in the authentication method configuration will also disable the collection of RBA data for the users that are not in the application repository, to prevent creating theirs accounts in the repository.