Configuration

The configuration consists of two parts, covering different aspects: One manages the determination of Risk Tags and one manages the Access Policies defining which roles a user can acquire in which way.

How Risk Tags are determined and how the login history is stored can be configured under  Loginapp >> Authentication Settings >> Risk Settings.  Leaving this property unconfigured disables all Risk Tags.

When configuring this plugin, the following settings can be configured:

Defines a list of plugins determining Risk Tags from all available information.

If configured, the login history is saved using this repository and is then available to all risk extractors. Note that existing installations might have to extend the database schema in order to enable this feature.

Database Schema

Up-to-date database schema templates can be found in the documentation: please refer to the "User Data Source" section on the main page.

The point at which a login history entry is written can be controlled by specifying a list of role patterns matching against the granted roles of a user. Therefore, if this property is set, an entry is only written for the current authenticated session, if the user has obtained at least one matching role. This is commonly used to restrict writing a login history entry after a Step-Up (thus the user has obtained the target 'Step-Up Role') so that the 'Typical * Risk Extractors' only consider Step-Ups. The reason is, that all those 'typical' risk extractors only consider the fact that a history entry is present and that they cannot distinguish between weak and strong logins.

In this case, the list can usually be left empty, meaning a login history entry is written once for each session after the first successful login.

If a Step-Up shall be avoided using a 'Typical * Risk Extractor'; meaning that if the same User-Agent or Geolocation is provided as in previous attempts and those previous attempts were successful Step-Ups, the 'Target Role' leading to the Step-Up must be configured here. Therefore, a login history entry is only generated if the user effectively performed a Step-Up. In case of only a weak login, no login history entry will be generated.

The user persister provides information about the user itself, for example, to determine tenancy or other contextual information.

The geolocation provider maps the client IP address to geolocation information, making that available to all risk extractors.

Currently, a geolocation provider for the MaxMind GeoLite2 databases is available.

The Access Policy defines the rules about processing Risk Tags, roles, and other information into new roles. There is a default Access Policy in the Application Settings plus every Target Application may define its own Access Policy, overriding the default if necessary.

Such a policy currently can only define Role Derivation Rules. Those rules are completely interaction-free and allow to define various preconditions (required roles, mandatory Risk Tags, and excluding Risk Tags) and if all preconditions are satisfied, a new role can be issued. This can be used to issue new roles based on Risk Tags and to implement the described scenarios above.

This role derivation is executed every time before being redirected to the target application and is applied iteratively until no more roles can be added. If after that the user is still missing a required role, Step-Up might be triggered (if that role can be obtained through Step-Up).