Evaluating the access policy

Risk Tags are only "facts" and as such neither positive nor negative. Thus, whether a role can be acquired because of a certain Risk Tag, or acquiring a role is prohibited by a Risk Tag, has to be specified using Access Policies.

Access Policies extend the rules governing the role acquirement process by also taking of Risk Tags into consideration. That is, a role may be acquired not only by completing an authentication step, but also by having a suitable risk/role combination.

For instance, if a role "restricted-access" is required, there might be several ways to get there:

1. Role "administrator" + Risk Tag "Access from internal network"
   An administrator is logging in from an internal network, therefore no additional authentication step is required
2. Role "administrator" + Risk Tag "typical geolocation" +Risk Tag "typical User-Agent"
   An administrator is logging in from a known location and with a known browser which he has both used multiple times before to perform the Step-Up, therefore no additional authentication step is required
3. Role "administrator"+Action "answer second factor"
   An administrator is logging in and no relaxation based on reduced risk is applicable. The administrator must present a second factor. (Traditional Step-Up scenario)

Access Policies can either be specified system-wide or individually for specific target applications.

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.

No Step-Up configured

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.

Step-Up configured

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.