Threat Guard with Akamai Edge Account Protector

This section describes the Akamai Edge Account Protector Signals and their corresponding actions in the Threat Guard system. To completely understand how these signals integrate with the overall Threat Guard service, please refer to the main Threat Guard documentation.

Akamai Edge Account Protector Signals for Risk Action Triggers

Action Signals from Akamai Edge Account Protector will be triggered based on one single header coming from Akamai Edge service called akamai-user-risk. This is the only input that will be considered by the Next Identity Threat Guard service to categorize a transaction as new device, high risk, medium risk, low risk, or impossible travel.

The akamai-user-risk header will be sent as a concatenated string of user information. Here is a sample of a potential akamai-user-risk header:

Akamai-User-Risk: uuid=86b37525-8047-4a3c-8d7a-23e99901da05;username=[[email protected]](mailto:[email protected]);ouid=m534264;requestid=19e22e;status=4;score=0;general=aci:0|db:Chrome 85|di:0fc91b5ec42f5a471c16a85e3e388ca57697c1a9|do:Mac OS X 10;risk=;trust=udbp:Chrome 85|udfp:25ba44ec3b391ba4ce5fbbd2979635e254775e7d|udop:Mac OS X 10|ugp:FR|unp:12322|utp:weekday_3;allow=0;action=monitor

Bot Detector: (not applicable) This risk detector signal is not currently configured to work with the Akamai Edge account protector; there is a separate Akamai Edge bot protector service will be enforced on the customer side before it reaches the Next Identity Threat Detector service.

Risk Detector: The source for the Risk Detector Signal will come from the “score” attribute within the Akamai-User-Risk header. The “score” attribute will be numerically between 0 and 100. The risk Detector has three levels (high risk, medium risk, and low risk), and those ranges will need to be provided by the customer, indicating a minimum and maximum value for each action with no overlapping values based on analyzing traffic patterns.

New Device Detector: The source for the New Device Detector Signal triggers will come from the attribute “general” within the Akamai-User-Risk header. By default, this will look for the value of nd but can be configured to a different value within the “general” attribute determined by the customer.

Impossible Travel Detector: Impossible Travel categorization will be triggered based on the attribute "risk" within the Akamai-User-Risk header. By default, this will look for the value of dce but can be configured to a different value within the “risk” attribute determined by the customer.

The values allowed for each category will be set at the global environment level (for example, all of a customer’s development environment applications will have the same triggered ranges). The values will not be configured at the property or client level.

The Next Identity Threat Guard service will allow that transaction to proceed when the akamai-user-risk header is absent. This is because the akamai-user-risk header will only be absent if the Akamai bot detector has allowed a known akamai or custom bot to proceed, and the risk evaluation on the akamai side will not occur in this scenario. The assumption is that under no circumstances will the Akamai Edge Account Protector service be off when the Next Identity Threat Guard service is enabled and configured to work based on those triggers.

Matrix of Available Actions Based on Signal Triggers from Akamai Edge Account Protector

📘

Note on the table below

The user only needs to complete the two-step verification process once. If in the scenario they are flagged twice (i.e., new device plus fraud detection), completing it once fulfills the requirement.

** step up auth against the login method is the only challenge method available as of this document writing. For email, the challenge (pin via email) is considered “step up” and not true two factor authentication. For mobile, the challenge (pin via mobile device) is already considered a two factor auth (something the user knows - password - and something they have - a mobile device). In a future state, if dynamic challenge options are available (mixing email and mobile for sign in and pin, for example) those would be added as options in the challenge here.