Configuration Reference

Overview

All HUMAN enforcer configuration is stored in a data group named pxconfig. Configuration values are read from this data group at runtime.

Modifying Configuration

To modify a configuration value, use the following command on the F5 shell:

$
modify /ltm data-group internal pxconfig records modify { KEY_NAME { data VALUE } }

Where:

• KEY_NAME is the name of the configuration directive
• VALUE is the value to set

Example: Enable blocking mode:

$
modify /ltm data-group internal pxconfig records modify { module_mode { data 2 } }

Example: Set a custom IP header:

$
modify /ltm data-group internal pxconfig records modify { ip_header { data X-Forwarded-For } }

Directives

Directives containing APP_ID

Some directives in the configuration may require a specific name which contains the appID of the application taken from the portal.

The name in the configuration must be identical to the name configured in the data group/virtual server/pool.

A mismatch in the name may lead to errors on the module.

Configuration Examples

Enable Blocking Mode

$
modify /ltm data-group internal pxconfig records modify { module_mode { data 2 } }

Enable Sensor Injection

When enabled, the iRule will automatically inject the HUMAN JavaScript sensor into HTML pages:

$
modify /ltm data-group internal pxconfig records modify { enable_sensor_injection { data 1 } }

Enable Score Header

Send the risk score to your origin server for custom handling:

$
modify /ltm data-group internal pxconfig records modify { enable_score_header { data 1 } }

This will add an x-px-score header to requests forwarded to your origin.

Enable Data Enrichment Header

Send the PXDE (PerimeterX Data Enrichment) payload to your origin:

$
modify /ltm data-group internal pxconfig records modify { px_data_enrichment_header_name { data x-px-data-enrichment } }

Set Custom IP Header

If your application is behind a proxy or CDN, specify the header containing the real client IP:

$
modify /ltm data-group internal pxconfig records modify { ip_header { data X-Real-IP } }

Enable Debug Logging

For troubleshooting, enable debug logging:

$
modify /ltm data-group internal pxconfig records modify { debug { data 1 } }

Credential Intelligence

The Credential Intelligence feature extracts credentials (hashed username and password) from login requests and sends them to HUMAN as additional info in the Risk API call. If credentials are found to be compromised, the enforcer can notify your origin via a header.

Enable Credential Intelligence

To enable Credential Intelligence, configure the following in the pxconfig data group:

$
# Enable the feature
$
modify /ltm data-group internal pxconfig records modify { ci_login_credentials_extraction_enabled { data 1 } }
$
$
# Set the login credentials extraction class name
$
modify /ltm data-group internal pxconfig records modify { ci_login_credentials_extraction_class { data px_login_credentials } }

Configure Protocol Version

Choose the appropriate protocol version for your login flow:

Standard Login (v2) - Username and password are submitted in a single request:

$
modify /ltm data-group internal pxconfig records modify { ci_credentials_intelligence_version { data v2 } }

Multi-Step SSO (multistep_sso) - Username and password are submitted in separate requests:

$
modify /ltm data-group internal pxconfig records modify { ci_credentials_intelligence_version { data multistep_sso } }

Configure Compromised Credentials Header

When credentials are checked, the enforcer adds a header to the request with the result:

$
modify /ltm data-group internal pxconfig records modify { ci_compromised_credentials_header { data x-px-compromised-credentials } }

The header value will be 0 (not compromised) or 1 (compromised), based on the HUMAN Risk API response.

Configure Login Success Reporting

To report whether login attempts were successful, configure one of the following methods:

Status-Based Reporting - Determine success based on HTTP response status code:

$
modify /ltm data-group internal pxconfig records modify { ci_login_successful_reporting_method { data status } }
$
modify /ltm data-group internal pxconfig records modify { ci_login_successful_status { data 200 } }

Header-Based Reporting - Determine success based on a response header:

$
modify /ltm data-group internal pxconfig records modify { ci_login_successful_reporting_method { data header } }
$
modify /ltm data-group internal pxconfig records modify { ci_login_successful_header_name { data x-login-success } }
$
modify /ltm data-group internal pxconfig records modify { ci_login_successful_header_value { data true } }

Configure Additional S2S Activity

Additional S2S activity sends enhanced login attempt data to HUMAN, including response code, login success status, and optionally the raw username.

Method 1: Origin Forwards Activity (Header-Based)

The enforcer adds activity data as headers for your origin to forward to HUMAN:

$
modify /ltm data-group internal pxconfig records modify { ci_additional_s2s_activity_header_enabled { data 1 } }

When enabled, the enforcer adds:

• px-additional-activity - JSON containing the activity data
• px-additional-activity-url - The HUMAN endpoint URL to forward the data to

Your origin is responsible for forwarding this data to HUMAN.

Method 2: Enforcer Sends Directly (Default)

When ci_additional_s2s_activity_header_enabled is 0, the enforcer sends the additional S2S activity directly via syslog during the HTTP response phase.

Include Raw Username in Additional S2S Activity

To include the raw (unhashed) username in the additional S2S activity:

$
modify /ltm data-group internal pxconfig records modify { ci_send_raw_username_on_additional_s2s_activity { data 1 } }