Authentication Risk Policies

An Authentication Risk Policy is a set of rules that defines the acceptable authentication mechanisms based on the authentication context.

This policy allows to evaluate the final risk based on the authentication context. Based on that result, it decides if authentication is needed and suggest the eligible mechanisms.

The system can apply only one Authentication Risk Policy. It evaluates the authentication policies by their priority (evaluationPriority) and applies the first one that matches the authentication context of the identity. If multiple policies share the same priority, the system evaluates them in random order.

Criteria to prioritize Authentication Risk Policies

Use these criteria to assign priority:

Criteria	Description	Configuration impact	Example
Application Sensitivity	Give highest priority to policies for the most critical or sensitive applications.	Set low `maximumAcceptableRisk` to enforce strict authentication.
Scope specifity	More specific policies get higher priority than broad or generic ones.	Targets specific `APP.name`	Policy for a single app > Policy for app group > Global policy
Specific business or user context	Policies that cover sensitive cases get higher priority.	Set high `minimumAuthenticationLevel` to require strong mechanisms.	Admin users, high-risk users, foreign IPs
Default fallback	Use a generic policy for all other policies with lowest priority.	Set high `maximumAcceptableRisk`, low `evaluationPriority`

Example

Code Snippet

XML

   <riskrba:AuthenticationRiskPolicy id="low-sensitive-apps">
      <name>Low Risk Applications</name>
      <evaluationPriority>10</evaluationPriority>
      <maximumAcceptableRisk>75</maximumAcceptableRisk>
      <matchingCondition>
         <script><![CDATA[APP.riskTolerance >= 50]]></script>
      </matchingCondition>
      <authenticationRules>
         <authenticationRule>
            <name>nonSensitiveApps</name>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[APP.authenticationLevel <= 25]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>10</minimumAuthenticationLevel>
         </authenticationRule>
         <authenticationRule>
            <name>nonSensitiveApps-default</name>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[return true]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>20</minimumAuthenticationLevel>
         </authenticationRule>
      </authenticationRules>
   </riskrba:AuthenticationRiskPolicy>
   
   <riskrba:AuthenticationRiskPolicy id="medium-sensitive-apps">
      <name>Medium Risk Applications</name>
      <evaluationPriority>20</evaluationPriority>
      <matchingCondition>
         <script><![CDATA[APP.riskTolerance >= 25 && APP.riskTolerance < 50]]></script>
      </matchingCondition>
      <maximumAcceptableRisk>50</maximumAcceptableRisk>
      <authenticationRules>
         <authenticationRule>
            <name>sensitiveApps</name>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[APP.authenticationLevel > 25 && APP.authenticationLevel <= 50]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>50</minimumAuthenticationLevel>
         </authenticationRule>
         <authenticationRule>
            <name>mediumSensitiveApps-default</name>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[return true]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>60</minimumAuthenticationLevel>
         </authenticationRule>
      </authenticationRules>
   </riskrba:AuthenticationRiskPolicy>

   <riskrba:AuthenticationRiskPolicy id="high-sensitive-apps">
      <name>High Risk Applications</name>
      <evaluationPriority>30</evaluationPriority>
      <matchingCondition>
         <script><![CDATA[APP.riskTolerance < 25]]></script>
      </matchingCondition>
      <maximumAcceptableRisk>25</maximumAcceptableRisk>
      <authenticationRules>
         <authenticationRule>
            <name>highlySensitiveApps</name>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[APP.authenticationLevel > 50]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>80</minimumAuthenticationLevel>
         </authenticationRule>
         <authenticationRule>
            <name>highSensitiveApps-default</name>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[return true]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>100</minimumAuthenticationLevel>
         </authenticationRule>
      </authenticationRules>
   </riskrba:AuthenticationRiskPolicy>

Policy Name	matchingCondition	evaluationPriority
`high-sensitive-apps`	`APP.riskTolerance < 25`	30
`medium-sensitive-apps`	`APP.riskTolerance >= 25 && APP.riskTolerance < 50`	20
`low-sensitive-apps`	`APP.riskTolerance >= 50`	10

high-sensitive-apps applies to the most critical apps (low risk tolerance). It has the highest priority (30), the lowest max acceptable risk (25), and demands strong authentication.
medium-sensitive-apps covers moderately sensitive apps, with medium priority (20) and authentication levels.
low-sensitive-apps covers less sensitive apps, has the lowest priority (10), allows higher risk, and requires lighter authentication.

Best practices and pitfalls

✅ Best Practices	❌ Pitfalls
Group similar applications or users under one policy to keep things simple. Clearly document each policy’s matching condition and priority. Always have a fallback policy	Avoid creating one policy per application unless necessary. Do not assign the same priority to multiple policies with overlapping conditions.

Configuration

🎯 To access the Authentication Risk Policies, click:

Access Risk -> Authentication Risk Policies
System -> Configurations -> Access Risk Service and import or export a file.

Property	Type	Mandatory	Description
id	`String`	MANDATORY	The unique id of the configuration item.
name	`String`	MANDATORY	The name of the configuration item.
description	`String`	OPTIONAL	The purpose of the configuration item.
evaluationPriority	`Integer`	MANDATORY	The value that sets the priority of this authentication policy. An higher value means higher priority. If two policies have the same value, the system chooses their priority at random. Default value : 0
maximumAcceptableRisk	`Integer`	MANDATORY	The maximum acceptable risk evaluated if this policy matches. The system only suggests authentication mechanisms under or below the maximum acceptable risk to the identity. Default value : 0
matchingCondition	`RuleDefinition`	OPTIONAL	Enter a `ConditionRule` in groovy script to determine whether this policy matches or not the identified user. If there is no `conditionRule` the policy always matches the identified user. To know more, see RBA Rule definition.
authenticationRules	`List of <authenticationRule>`	OPTIONAL	The definition of the authentication rules to apply. Define the criteria of each rule inside a `authenticationRule` property. When an authentication rule matches, the system increases the requested authentication level.

authenticationRule

Property Name	Type	Mandatory	Description
name	`String`	MANDATORY	The name of the rule. The system returns this value in the RBA output if the rule matched.
enabled	`Boolean`	OPTIONAL	true: Enable the rule false: Disable the rule Default value: true
matchingCondition	`RuleDefinition`	MANDATORY	Enter a `ConditionRule` in groovy script to determine whether this rule matches or not. If there is no `conditionRule` the policy always matches. To know more, see RBA Rule definition.
minimumAuthenticationLevel	`Integer`	MANDATORY	The minimum authentication level required if `matchingCondition` matches. The Identity must use an authentication mechanism greater or equal than the minimum authentication level to access the target application. If several `AuthenticationRuleDefinition` match, then the higher level (i.e. the most constraining) is retained.

Example

XML

<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>USR Portal Authentication Policy</name>
      <description>USR Portal Authentication Policy</description>
      <authenticationRules>
         <authenticationRule>
            <enabled>true</enabled>
            <matchingCondition>
               <script><![CDATA[return true]]></script>
            </matchingCondition>
            <minimumAuthenticationLevel>0</minimumAuthenticationLevel>
            <name>RR-APP-1</name>
         </authenticationRule>
      </authenticationRules>
      <evaluationPriority>100</evaluationPriority>
      <matchingCondition>
         <script><![CDATA[
           // Assess the application the user wants to access
           def appName = APP?.name as String ?: ""
          return (appName.contains("https://myApp-internalUrl"))]]>
         </script>
      </matchingCondition>
      <maximumAcceptableRisk>100</maximumAcceptableRisk>
   </riskrba:AuthenticationRiskPolicy>
</kit:DataSet>