Configurational Classes

The HUMAN BigIP module allows you to set a number of configurational classes (data groups) to control which routes are processed in different ways.

Whitelist Routes

Routes added to this class will bypass HUMAN enforcement entirely.

1. On Local Traffic > iRules > Data Group List create a new Data Group.
2. Set the Name to px_<APP_ID>_whitelisted_routes. Make sure to replace <APP_ID> with your HUMAN app id.
3. Set Type to String.
4. For each route you wish to allow, set the String property of String Record to the prefix of the route and click Add.
5. Click Finished.
6. On the iRule, make sure the value of whitelisted_routes_class directive is the same as the name you provided in step 2.

Whitelisted Query Parameters

Query parameters added to this class will be excluded from the URL sent to HUMAN for risk evaluation. This is useful for removing sensitive or dynamic parameters from the evaluation.

1. On Local Traffic > iRules > Data Group List create a new Data Group.
2. Set the Name to px_<APP_ID>_whitelisted_query_params. Make sure to replace <APP_ID> with your HUMAN app id.
3. Set Type to String.
4. For each URI query parameter you wish to whitelist:
   • Set the String property to the query parameter key name
   • Set the Value property to a regex pattern matching the values to whitelist
   • Click Add
5. Click Finished.

Example: To whitelist the session_id parameter with any value:

• String: session_id
• Value: .*

Specific Routes

Routes added to this class will be the only routes that HUMAN enforces. All other routes will bypass enforcement.

1. On Local Traffic > iRules > Data Group List create a new Data Group.
2. Set the Name to px_<APP_ID>_specific_routes. Make sure to replace <APP_ID> with your HUMAN app id.
3. Set Type to String.
4. For each route you wish to enforce, set the String property of String Record to the prefix of the route and click Add.
5. Click Finished.
6. On the iRule, make sure the value of specific_routes_class directive is the same as the name you provided in step 2.

Sensitive Routes

Routes added to this class will trigger a server-to-server risk API call regardless of the cookie score. This provides higher security for critical endpoints.

1. On Local Traffic > iRules > Data Group List create a new Data Group.
2. Set the Name to px_<APP_ID>_sensitive_routes. Make sure to replace <APP_ID> with your HUMAN app id.
3. Set Type to String.
4. For each sensitive route, set the String property of String Record to the prefix of the route and click Add.
5. Click Finished.
6. On the iRule, make sure the value of sensitive_routes_class directive is the same as the name you provided in step 2.

Monitor Routes

Routes added to this class will be processed in monitor mode regardless of the global module_mode setting. This allows you to enable blocking mode globally while keeping specific routes in monitor mode, or vice versa.

The class supports domain/path based configuration for more granular control.

1. On Local Traffic > iRules > Data Group List create a new Data Group.
2. Set the Name to px_<APP_ID>_monitor_routes. Make sure to replace <APP_ID> with your HUMAN app id.
3. Set Type to String.
4. For each route you wish to set to monitor mode:
   • Set the String property to the domain and path (e.g., example.com/api)
   • Click Add
5. Click Finished.

Login Credentials Extraction

This class defines the endpoint where login credentials should be extracted. The credentials are hashed and sent to HUMAN for breach detection.

1. On Local Traffic > iRules > Data Group List create a new Data Group.
2. Set the Name to match the value configured in ci_login_credentials_extraction_class (e.g., px_login_credentials).
3. Set Type to String.
4. Add the following records with their corresponding values:

5. Click Finished.

Example: JSON Body Login

For a login endpoint at /api/auth/login that accepts POST requests with JSON body:

1
{
2
  "email": "user@example.com",
3
  "password": "secretpassword"
4
}

Configure the class with these records:

Example: Form POST Login

For a login form that submits to /login with form-urlencoded data:

Supported Content Types for Body Extraction

When sent_through is set to body, the enforcer supports:

• application/json - JSON request bodies
• application/x-www-form-urlencoded - Form-encoded request bodies

The enforcer automatically detects the content type based on the Content-Type or Accept request header.

Extraction from Headers

When sent_through is set to header, the user_field and pass_field values specify the header names:

Extraction from Query String

When sent_through is set to query-string, the user_field and pass_field values specify the query parameter names:

This would extract credentials from a URL like /login?user=john&pass=secret.