6.7 Risk-Based Policies

6.7.1 Configuring Risk-Based Authentication

Configuring risk-based authentication involves the following steps:

  1. Create a risk policy. For more information, see Configuring a Risk Policy.

  2. Create a method for the risk-based authentication class. For more information, see Configuring a Method for an Authentication Class.

  3. Create a contract for the risk-based authentication class. For more information, see Configuring a Contract for an Authentication Class.

You must consider the following points while configuring the risk-based authentication:

  • A rule must be included in a risk policy. A rule can exist in multiple risk policies.

  • A risk-based authentication class maps to only one risk policy and vice versa.

  • If a rule condition is not met, the score associated with that rule is added to the risk score. If the rule condition is met, the specified action is executed.

  • The risk level is determined based on the total risk score, that is the sum of the scores of all rule conditions that are not met.

  • If a rule is configured to allow or deny access and exit the policy when a condition is met, the risk score is zero as other rules in the group are not evaluated.

Configuring a Risk Policy

Before creating a risk-based policy, determine the following to understand the criteria for defining a rule:

  • The application or resource you want to protect.

  • The parameters you want to assess during a login attempt.

  • The risk score for each parameter.

  • The risk levels for risk scores.

  • The action for the risk levels.

  • If you want to record the details of risk assessment.

  • If you want to store history details from the risk assessment in MySQL, MicroSoft SQL Server, or Oracle database.

  • If you want to perform profiling on user login events based on the geolocation of the user.

  • If you want to assess the risk before a user attempts to login.

Configuring a risk policy includes the following three parts:

Adding a Risk Policy

  1. Click Policies > Risk-based Policies > Risk Policy.

    If there is no risk policy configured, clicking Risk Configuration opens the Overview page.

  2. Click the Create Risk Policy icon.

    NOTE:To create an identical copy of any existing risk policy:

    1. Click Policies > Risk-based Policies > Risk Policy.

    2. Locate the policy you want to clone and click the Clone Risk Policy icon. All rules and risk levels configured for the existing policy are copied to the new policy.

    3. Specify a name for the new policy and assign a cluster and an authentication class.

  3. Under Add Risk Policy, specify the following details:

    Risk Policy Name: Specify a name for the policy.

    Policy Description: Describe the purpose of this policy.

    Assign Policy To: Select the Identity Server cluster and then select an authentication class. You can select the class from the list of existing classes or you can create a new class.

    NOTE:If you select an existing class, settings of the selected class are overwritten with values of this policy.

    For creating a new class, perform the following steps:

    Configuring a Risk-Based Authentication Class
    1. Select either of the following options:

      Create Risk-based Auth Class:

      Calculates the risk score after authentication. For more information, see Risk Assessment and Risk Mitigation after Authenticating a Login Attempt.

      Create Risk-based Pre-Auth Class

      Calculates the risk score before authentication. For more information, see Risk Assessment and Risk Mitigation before Authenticating a Login Attempt.

      NOTE:To modify an existing authentication class go to Identity Server > cluster > Edit > Local > Classes.

    2. Specify a name for the class.

    3. Select Record User History to record the user’s login details.

      Before enabling this option, ensure that you have enabled recording user history in Policies > Risk Configuration > User History and configured a database. For more information, see History: and Configuring an External Database to Store User History.

      NOTE:The Record User History option is available only for Risk-based Auth Class.

    4. Select Use Cumulative Risk Score to add current risk score of the session to this evaluation.

      If you select this option, ensure that you have defined appropriate risk levels in this class to accommodate the cumulative value. For more information, see Cumulative Scoring:.

    5. To send the user name, risk score, and risk level of a specific login attempt to an external REST interface, click Score Sharing URLs and specify the URL of the interface. The external REST interface uses this score information to perform additional actions on the user’s identity.

      (Optional) Specify the REST endpoint authentication credential. Whenever the risk score is sent to the REST endpoint, the endpoint sends these credentials as a basic authentication header. If the REST endpoint is protected by using basic authentication, then this credential is used.

      If Reduce Score is enabled, the reduced risk score is sent to the REST endpoint for a successful additional authentication.

      After enabling Score Sharing URLs, you must enable the identified risk scores for sharing.

      You can enable two Score Sharing URLs. If the REST endpoint is down, a warning message is logged in the log file (Linux: catalina.out; Windows: stdout.log). If the REST endpoint is down during risk score sharing, the risk is not cached and will not be shared later.

      NOTE:The Score Sharing URLs option is available only for Risk-based Auth Class.

    6. Click Save.

  4. Continue with Configuring Policy Rules.

Configuring Policy Rules

You can select a rule from the existing list or create a new rule and then assign it to the risk policy. You can assign multiple rules to a policy. The rules are executed in the top to bottom sequence. You can drag and drop to change the priority and sequence of rules. Rules for which action is defined as Allow Access, Deny Access, or Exit with Risk Level as specified risk level are executed as specified in the rule irrespective of the risk score accumulated for other rules that previously failed.

For each rule you want to add to a policy, you must perform the following steps:

  1. To create a new rule, perform the following actions:

    1. Click Actions > Create Rule.

    2. Specify a rule name.

    3. Select a rule definition. For details, see Step 3 in Configuring Rules.

    4. Click OK.

    5. Define actions for the rule.

      Condition

      Action

      If rule condition is met

      Select any of the following options:

      • Proceed to Next Rule: The next rule in the execution sequence is executed.

      • Allow Access and Exit Policy: No other rules of this policy is executed and the user will get access to the resource.

      • Deny Access and Exit Policy: No other rules of this policy is executed and the user will be denied access.

      • Exit with Risk Level as: Select a risk level. You can also create a risk level and then assign it to the rule. For information about creating a new risk level, see Configuring Risk Levels. No other rules in this policy are executed. The action specified for that risk level is executed.

      If rule condition is not met, add risk score

      Specify the risk score that will be stored when the rule evaluation fails.

    6. Click Save.

      NOTE:You can also create a rule here Policies > Risk-based Policies > Rules > New. See Configuring Rules.

  2. To select a rule from the existing list, perform the following actions:

    1. Under Policy Rules, click Actions > Add Existing Rule.

    2. In Risk Rule, select the rule you want to add from the list.

    3. Define actions for the rule. For details, see Step 1.e.

    4. Click Save.

      NOTE:To validate the rule configuration and view the result when a condition is met, click Actions > Toggle Validate. For more information, see Understanding How to Use the Validate Tool to Emulate Total Risk Score and Risk Levels.

  3. Continue with Configuring Risk Levels.

Configuring Risk Levels

  1. Under Risk Levels, click Actions > Add Risk Level.

  2. Specify the following details:

    • Risk Level: Select a risk level to associate with the risk score. If you select Other, specify a name to identify the custom risk level.

    • Risk Score: Specify a risk score to be associated with the risk level. The risk score indicates a value that is stored in the database after rule evaluation fails.

    • Action: Select an action for this risk score.

      If you select Additional Authentication under Action, you can either select a class or a method to configure the step-up authentication. Typically, the step up to a method is used when branding, overwriting of users, or a change of userstore is required. If the userstore of the Additional Authentication is same as the risk-based authentication class and no additional branding is needed, then use a class.

    • Reduce Score: After a successful additional authentication, you can configure to reduce the associated risk score. Specify the value that you want to reduce from the risk score in this field. For more information, see Risk Score Reduction after a Successful Additional Authentication:.

    • Share Score: Select this option if you want to send the risk score of this risk level to the URL specified in Score Sharing URLs in the associated authentication class. You can share risk scores only for the risk levels configured for Risk-based Auth Class.

      This option is available only if at least one Share Score URLs is configured for the authentication class.

  3. Click Save.

  4. Continue with Configuring a Method for an Authentication Class.

Configuring a Method for an Authentication Class

Perform the following steps:

  1. Click Local > Method > New to create a new method for the risk based authentication class.

  2. Specify a name to identify the method.

  3. Select the risk-based authentication class from Class.

  4. Deselect Identifies User.

    NOTE:If the policy is using Risk-Based Pre-Auth Class, this options must be selected at least in one method of the contract.

  5. Select a user store from the list of Available User Stores.

  6. Click Finish.

    IMPORTANT:In a risk-based authentication class, properties configured for the risk-based authentication method are ignored. So, if you want to configure additional properties, add the property to the risk-based authentication class.

  7. Continue with Configuring a Contract for an Authentication Class.

Configuring a Contract for an Authentication Class

Perform the following steps:

  1. Click Local > Contract > New to create a new contract for the risk based authentication class.

  2. Specify a name to identify the contract.

  3. You can either use an existing authentication contract or create a new authentication contract. For example, for Risk-based Auth Class, you can add the default Name/Password – Form method as the first method and risk-based authentication method as the second method. For Risk-based Pre-Auth Class, the risk-based authentication method must be configured as the first method.

  4. Click Next to configure a card for the contract. For more information about configuring contracts, see Configuring Authentication Contracts.

    NOTE:If you want to use this contact in federation, ensure that you assign this contract to a protected resource.

Configuring Rules

Perform the following steps:

  1. Click Policies > Risk-based Policies > Rules > New.

  2. Specify a name for the rule.

  3. Select a rule type in Rule Definition based on your requirement and specify the following details:

    Rule Type

    Procedure

    IP Address

    1. To manually add IP addresses, select Manually enter the Datasource. You can specify a single IP address, IP address range, IP address subnet, or upload a text file containing IP addresses. To specify the IPv4 subnets, use the Classless Inter-Domain Routing (CIDR) notation.Click Add to List.

      Sample text format

      # Example IP List

      10.0.0.0

      172.16.0.0

      192.168.0.0

      Each entry in the text files must be on a separate line.

    2. To consider the list of IP addresses provided by an external provider or an internal web service, select Dynamically consume from the Datasource.

      1. Specify URL of the provider.

      2. In Connection Timeout, specify the time in second. After this specified time, an unresponsive connection is closed. For example, 5 seconds.

      3. In Refresh Interval, specify the time in second. The connection will be refreshed at the specified interval. For example once in 86400 seconds.

      The external provider provides the list of IP addresses in text or JSON formats.

      Sample text format

      # Example IP List

      10.0.0.0

      172.16.0.0

      192.168.0.0

      Sample JSON format

      ["10.0.0.0","172.16.0.0","192.168.0.0"]

    3. Specify how the conditions for the rule must match. The available options are Is and Is Not. For more information about Is and Is Not conditions, see Table 5-1, Risk-based Authentication Terms.

    4. To validate the user history recorded in the database, select Check user history. You can use this option only when Record user history is enabled in the User History tab.

      IMPORTANT:You cannot specify the IP subnet in the IPv6 format. Instead, you can use the IP range condition and define it in the IPv6 format.

    Cookie

    1. Specify the name of the cookie.

    2. Specify the value of the cookie. The different search criteria that you can use are Is and Is Not. For more information about Is and Is Not condition, see Table 5-1, Risk-based Authentication Terms.

    3. [Optional] If the cookie is not found, but you want to create a cookie after the user authenticates, select Create cookie if the user authenticates successfully.

      1. Specify the validity of the cookie in days.

      2. Specify the path for the cookie.

        IMPORTANT:A cookie is set only when the user is authenticated by using second-factor authentication. The cookie is not created if the risk is assessed to be low and the user authenticates by using primary authentication method.

    HTTP Header

    1. Specify the HTTP header Name.

    2. Specify the HTTP header value that you want to search for an HTTP header that includes a specific value. For example, if you want to search for an HTTP header that includes the value NetIQ, you can use the search criterion Equals. Whereas, if you want to query for an HTTP header that does not include the value NetIQ, use Does Not Contain.

    User Profile

    1. Select an LDAP attribute from the list. If you want to define a custom LDAP attribute, click New.

    2. Specify how the conditions for the rule must be matched.

    3. Specify the value of the attribute to be searched. For example, if you selected the LDAP attribute birthDate for rule creation, specify the birth date to be searched.

    User Last Login

    1. Specify the name of the last login cookie.

    2. Specify the path for the cookie.

    3. Specify the validity of the cookie in days.

    4. If you want the cookie to be secured by HTTPS, enable Secure Cookie.

    5. Specify the number of days the cookie can be accessed from the same device or system. This value must be less than the value in Max Age.

    6. Specify the crypto key to encrypt the cookie.

      IMPORTANT:A User Last Login cookie is set only when the user is authenticated by using second-factor authentication. A User Last Login cookie is not created if the risk is assessed to be low and the user authenticates by using primary authentication method.

    User Time of Login

    1. Select Is/Is not condition based on your requirements. This determines how the conditions for the rule must be matched.

    2. Specify the date and time of the user login.

    3. To validate the user history recorded in the database, select Check user history. To use this option, enable Record User History in the User History tab.

    Device ID

    1. Specify a name to identify the cookie.

    2. Specify a path where the cookie has to be stored.

    3. Specify the validity of the cookie in days.

    4. If you want the cookie to be secure, select Secure Cookie. This ensures that the cookie is protected by HTTPS.

    5. Specify the value that the cookie must contain. Select a value(s) from the list of cookie parameters.

      NOTE:For pre-authentication risk-based class, do not select username.

      The different search criteria you can use are Is and Is Not. For more information on how Is and Is Not condition can alter the search criteria, see Table 5-1, Risk-based Authentication Terms

      IMPORTANT:A Device ID cookie is set only when the user is authenticated by using second-factor authentication. A Device ID cookie is not created if the risk is low and the user authenticates by using the primary authentication method.

    Geolocation

    1. Specify the geolocation details.

    2. Select Is/Is not condition based on your requirements. This determines how the conditions for the rule are matched.

    3. To validate the user history recorded in the database, select Check user history. To use this option, select Record User History in the User History tab.

    External Parameter Configuration

    1. Select Negate Result to reverse the result of the rule evaluation. For example, if you have defined this rule to get authentication details of a request using a specific IP address, you can use Negate Result to define the rule to not consider inputs originated from that IP address.

    2. Under External Parameter, add the following details for a parameter set:

      1. Name of the parameter.

      2. Specify the regular expression if required.

        For example, suppose an external source sends the following value for the Virtual IPv4 parameter:

        The Virtual IP address is 127.0.0.1

        To extract the IP address from this string, you can specify a regular expression as follows:

        (?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)

        This regular expression extracts the IP address 127.0.0.1 from the string and uses it for evaluating the configured condition. For more information about regular expression syntax, see the Javadoc for java.util.regex.Pattern.

      3. Select a relational or string operator to define a relationship between the parameter and parameter value. For example, whether a parameter must contain the specified parameter value or it must not be equal to the specified value. The available operators include contains, does not contain, is equal to, is equal to ignore case, is greater than, is greater than or equal to, is less than, is less than or equal to, in between, is not equal to, is not equal to ignore case.

      4. Specify a parameter value for evaluation.

      5. Click Add Parameter to add more parameters in this parameter set. You can define multiple parameters in a parameter set.

    3. (Conditional) Click Add Parameter Set to define additional parameter set. You can define multiple parameter sets.

    4. If you have defined two or more parameter sets, specify how the conditions for the parameters must match. The available options are Or and And. For more information, see Combination Rule in Table 5-1, Risk-based Authentication Terms.

    For an example about configuring external parameter, see Using External Parameters in Risk Assessment:.

    NOTE:To use this rule, you must create a custom class to retrieve details from an external provider. For more information, see User Information Methods and Creating an Authentication Class in the NetIQ Access Manager 4.2 Developer Guide.

    Custom Rule

    1. Specify a fully qualified name of the custom class for which you want to create a custom rule. For example: com.Company.test.MyCustomclass.

    2. Select Check user history to check the user history details if the rule execution fails.

    3. Select Negate Result if you want to reverse the results of rule execution. For example: if you have defined a rule to track authentication attempts from a specific geolocation, you can use Negate Result to define a rule to allow authentication if the user logging in is not from that geolocation.

    4. Click Add Property to add custom properties and values.

  4. Click Finish.

Configuring User History

Recording the user history involves the following steps:

  1. Configuring an external database to log history records. For more information, see Configuring an External Database to Store User History.

  2. Enabling user history. For more information, see Enabling User History.

  3. Enabling user history while configuring a rule. For more information, see Configuring Rules.

  4. Configuring user history for a risk policy that is linked to an authentication class. For more information, see Configuring a Risk-Based Authentication Class.

    When you choose to record user history details for a risk policy that is linked to an authentication class, you get the flexibility to segregate the history details as per your requirement.

    Consider a situation where you have configured the following two risk policies:

    • One risk policy assesses authentication requests from internal users in an organization.

    • Another risk policy assesses authentication requests from users external to the organization.

    To record the history details for internal users only, enable the recording of user history at the risk-based authentication class that is used to authenticate the internal users.

Enabling User History

  1. Click Policies > Risk-based Policies > User History.

  2. Select Enable User History to save the user session details in the database.

  3. Under History Settings, you can either specify the number of days of history to consider during the rule execution or select the option to consider all historical records. For example, if you specify 10, it indicates that the details of last 10 days must be considered during the rule execution. If you do not specify the number of days, all historical records are considered for the execution.

    NOTE:In Access Manager 4.1, you are required to specify the number of entries instead of the number of days. If you have configured the number of entries in Access Manager 4.1 and then upgrade to version 4.2, the configuration is ignored.

  4. (Conditional) To store details in eDirectory, select Built-in Data Store.

    NOTE:In a production environment, it is strongly recommended that you do not use eDirectory as the data store.

  5. (Conditional) If you choose to save the session details in an external database, select External Database.

    1. Specify the name to identify the driver.

    2. Select the Database Driver. The driver path and dialect are displayed. You can change the driver and dialect details if required.

    3. Specify the Username and Password to access the database.

    4. Specify the URL to access the database.

      NOTE:To configure MySQL as the database, ensure that the database URL is specified as mysql://db_user:db_user@localhost/netiq_risk?autoReconnect=true.

      For information about configuring an external databases, see Configuring an External Database to Store User History.

  6. Click OK.

Configuring Geolocation Profiling

  1. Click Policies > Risk-based Policies > Geolocation.

  2. Select Enable Location Profiling to fetch location data from a geolocation database. This helps to identify the location of the user based on the IP address details.

  3. Select a Geolocation Provider. The available options are:

    Database

    Details

    Neustar Service

    • Specify the API Key and API Secret.

    • Specify the Web Service URL.

    Custom Provider

    • Specify a name to identify the provider.

    • Specify the fully qualified name of the JAVA class.

    • Click Add Property to add properties to the custom class.

  4. Click OK.

Configuring NAT Settings

You can configure the Identity Server to retrieve IP addresses in a NAT environment.

  1. Click Policies > Risk-based Policies > NAT Settings.

  2. Specify the name of the field to use for fetching the IP address of the client.

  3. Specify the regular expression to retrieve the client IP address from the HTTP header value.

    When you use the regular expression .* , the rule execution fails even if the client IP address exists in the list of multiple IP addresses. So, if you want to retrieve an IP address from a list of multiple IP addresses, modify the regular expression accordingly.

    For example: If you specify the regular expression as .*?(?=,), the Identity Server considers the first IP address in the list to calculate risk.So, if the list of IP addresses are similar to 10.20.20.1,10.30.30.1,10.40.40.1, the regular expression .*?(?=,) returns IP address 10.20.20.1.

  4. Click OK to save the configuration.

6.7.2 Configuring an Authorization Policy to Protect a Resource

In an authorization policy, you can define a condition group that uses risk scores from the Identity Server to protect a resource.

Defining a Condition Group and Assigning Actions:

  1. Select Policies > Policies.

  2. Select the policy container and click New.

  3. Specify a name for the policy and select Access Gateway: Authorization for the type of policy.

  4. From the Condition Group, select Risk Score. For more information about Comparison, Value, and Result on Condition Error, see Risk Score.

  5. Select an action. For more information about actions, see step 7 in Creating Access Gateway Authorization Policies.

  6. Click OK to save the changes.

6.7.3 Enabling Auditing for Risk-Based Authentication Events

Access Manager logs the following risk-based authentication audit events:

  • Risk-Based Authentication Succeeded

  • Risk-Based Authentication Action Involved

  • Risk-Based Authentication Failed

For information about how to configure Access Manager to send these events to a Novell Auditing Server, see Enabling Identity Server Audit Events.

6.7.4 Enabling Logging for Risk-Based Authentication

To enable logging for risk-based authentication, perform the following steps:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Logging.

  2. Select Enabled under File Logging.

  3. In the Component File Logger Levels section, specify any one of the following options for application logs:

    • Severe: Logs serious failures that can stop system processing.

    • Warning: Logs potential failures that have minimal impact on execution.

    • Info: Logs informational events.

    • Verbose: Logs static configuration information.

      The system logs any configuration errors under one of the three primary levels: Severe, Warning, and Info.

    • Debug: Logs events for all other log levels: Severe, Warning, Info, and Verbose.

  4. Click OK.

For more information, see Identity Server Logging.

6.7.5 Risk-Based Authentication: Sample Configuration

This section explains the use cases and their configuration steps demonstrated in the Try Now option on the Risk Configuration > Overview interface.

Let us assume a company named Company1 wants to control access to its resources. There are two users. One is a permanent employee of Company1 and another is a trainee at Company1. This configuration will refer the regular employee as Employee and the trainee as Trainee.

Company1 wants to achieve the following actions:

  • Scenario 1: Trainee or Employee is accessing the resource by using the internal network: Allow access.

  • Scenario 2: Trainee is accessing the resource by using the external network: Deny access.

  • Scenario 3: Employee is accessing the resource by using the external network with a known device: Ask for additional authentication.

  • Scenario 4: Risk associated with accessing the resource from an external network can depend various conditions. The following are the conditions with equal weightage:

    • Employee’s request contains a cookie from the Intranet site or has a header from the Payroll site, indicating that Employee was successfully logged into these resources earlier.

    • Employee is logging in during normal work hours that is 9 am to 5 pm

    All conditions are evaluated. The risk decreases as the number of conditions met increases. The action performed depends on the risk score and associated risk level.

The following diagram illustrates the rule execution logic of the demo risk policy:

You can configure rules for these scenarios and arrange the rules in the order of priority on the UI. The rules are executed based on the priority from top to bottom. You can drag and drop rules on the UI to change their priority.

In this sample, the following five rules are created and executed in the same sequence:

Sequence of Execution

Rule Name

Action

1

DemoRule_InternalNetwork:

If Trainee or Employee is in the internal network, then allow access and exit the policy.

If not, add risk score of 20 and proceed to the next rule.

2

DemoRule_TraineeUser

If Trainee is accessing from an external network, deny access and exit the policy.

If Employee is accessing from an external network, add risk score of 20 and proceed to the next rule.

3

DemoRule_KnownDevice

If Employee is using a known device to access the resource from an external network, prompt for an additional authentication and exit the policy.

If the Employee is using a unknown device to access the resource from an external network, add risk score of 20 and proceed to the next rule.

4

DemoRule_Combo

If Employee is accessing with a cookie from the payroll site or HTTP Header value contains loggedIn, proceed to the next rule with the total risk score accumulated due to the failure of the above three rules.

For example, assume the risk score for each rule is 20. If the condition for this rule is met, then proceed to next rule with a risk score 60. If the condition for this rule is not met, then proceed to next rule with a risk score of 80.

NOTE:To use this rule, you must set cookies or headers per domain with a path of /, so that the Identity Server can receive them.

5

DemoRule_TimeOfLogin

If Employee is logging in using an external network and time is in between 9 AM to 5 PM, proceed to the next rule. The risk score will depend on whether the condition of the DemoRule_Combo was met.

If the conditions of both DemoRule_Combo and DemoRule_TimeOfLogin rules fail, the total risk score will be 100 and access will be denied.

The following steps have been performed to configure the demo risk policy for the identified scenarios:

  1. Go to Policies > Risk-based Policies > Risk Policy.

  2. Click the Create Risk Policy icon.

  3. Under Add Risk Policy, specify the following details:

    Risk Policy Name: Specify Demo_RiskPolicy.

    Policy Description: Specify the purpose of this policy.

    Assign Policy To: Select the Identity Server cluster and then configure an authentication class.

    1. Select Create Risk-based Auth Class.

    2. Specify Class Name as Demo_RBAAuthClass.

    3. Click Save.

  4. Create the following rules:

    Under Policy Rules, click Create Rule and specify the following values:

    1. DemoRule_InternalNetwork

      • Rule Name: DemoRule_InternalNetwork

      • Rule Definitions: IP Address Rule

      • Specify the IP address range as 121.1.1.1 - 121.121.255.255 and click OK

      • If rule condition is met, then: Allow Access and Exit Policy

      • If rule condition is not met, add risk score: 20

      • Click OK.

    2. DemoRule_TraineeUser

      • Rule Name: DemoRule_TraineeUser

      • Rule Definitions: User Profile

      • Select EmployeeType, Equals, and then specify Trainee. Click OK

      • If rule condition is met, then: Deny Access and Exit Policy

      • If rule condition is not met, add risk score: 20

      • Click OK.

    3. DemoRule_KnownDevice

      • Rule Name: DemoRule_KnownDevice

      • Rule Definitions: Device ID Rule

      • Do not change the default values and click OK

      • If rule condition is met, then: Exit with Risk Level as

      • Select Risk Level: Medium

      • If rule condition is not met, add risk score: 20

      • Click OK

    4. DemoRule_Combo

      • Rule Name: DemoRule_Combo

      • Rule Definitions:

        Rule 1: Cookie Rule

        Cookie Name: IntranetCookie

        Cookie Value: is test 12

        Rule 2: HTTP Header Rule

        HTTP Header Name: PayrollAccessHeader

        HTTP Header Value: Contains loggedIn

      • Combination Rule Definition: In Condition Group, click Assign Rules and then select both rules. Select OR in Group Operator

      • If rule condition is met, then: Proceed to Next Rule

      • If rule condition is not met, add risk score: 20

      • Click OK

    5. DemoRule_TimeOfLogin

      • Rule Name: DemoRule_TimeOfLogin

      • Rule Definitions: User Time of Login Rule

        User time of login: is

        Day: Monday to Friday

        Time: 9 AM to 5 PM

      • Click OK

      • If rule condition is met, then: Proceed to Next Rule.

      • If rule condition is not met, add risk score: 20

      • Click OK

  5. Under Risk Levels, click Actions > Add Risk Level and create the following risk levels:

    • Low

      Field

      Value

      Risk Score

      Less than 40

      Risk Level

      Low

      Action

      Allow Access

    • Medium

      Field

      Value

      Risk Score

      Between 40 and 80

      Risk Level

      Medium

      Action

      Authenticate using Trust levels

    • High

      Field

      Value

      Risk Score

      Greater than 80

      Risk Level

      High

      Action

      Deny Access

  6. Click OK.

  7. Create an authentication method. For more information, see Configuring a Method for an Authentication Class.

  8. Create a contract. For more information, see Configuring a Contract for an Authentication Class.

  9. Assign the contract to the protected resource.