¶ Configure API Adaptive Risk Authentication
As we know there are several adaptive authentication products that are aimed to interact with human users, like, multi-factor authentication (MFA), depending on the situation or user location.
In the case of Adaptive Risk Authentication is that it protects App-to-App comunication where and API which is publicly accessible can be protected based on certain rules and configuration that involves user location, user browser agent, user remote IP and time of access. All of this rules together will tell an API Server if an API Client is legit and if it can be allowed, denied or challenged.
¶ Adaptive Risk Score Bands Configuration
There are 3 bands that needs to be configured with the desired score the API Provider wants the API Clients to be filtered out.
- The first band is the Deny band. If an API Client is validated and the score fells into the range configured for the band as in the example, between 0 and 25, then the API Client is denied and it won't be able to complete the API call, this if API Server restrict it based on the Adaptive Auth validation.
- The second band is the Challenge band. If an API Client is validated and the score fells into the range configured for the band as in the example, between 25 and 75, then the API Client must resolve a TOTP challenge by either generating it own token or by requesting the token from the Adaptive Auth Serverr using the API Client public key.
- The third band is the Allow band. If an API Client is validated and the score fells into the range configured for the band as in the example, between 75 and 100, then the API Client is accepted and it should be able to complete the API call.
¶ How API Client obtains the validation score?
Note that in the next part where rules are configured also a weight must be assigned for every section, this score must match 100 in total for all 4 section. Is up to the API Provider to assign the corresponding weight according to the security rules or internal cosideration to which rule set has more or less risk and that will determine the final weight of every section.
¶ IP Restriction Configuration
Remote address or IP address rules can be set in this section. These rules will fiter all API Clients based on a range, meaning, an IP range is a set of IPs that are consecutive. They can be assigned to a specific subnet. It is the trailing host portion of an IP address. You can set up devices within a local network under one IP Range.
For example you can define:
- Start address: 192.168.0.1
- End Address: 192.168.168.0.50
This tells the Adaptive Auth Server to allow only API Clients with a remove address between host IDs from 1 to 50.
The API Provider can define as many ranges as needed, according to their needs or country restrictions.
¶ Location Configuration
The API Client location can also be evaluated and validated. Adaptive Auth Server uses API Client remote address to determine API Client location, for this an external database with A Simple Public IP Address API where Country, City and Geo location can be determined.
This is very helpful if you want to allow your clients to access your application if they are in a specific country or city.
See the examples in the section for location rules set and add your requirements for location restriction.
¶ Time of Access Configuration
Time of access, also known as "time-based access controls," are security measures that limit API Clients access to systems or data based on specific timeframes.
There are API endpoints that API Providers want to protect based on the time of day. This way, API Providers can ensure e.g. employees can only access sensitive data, like customer info or financial details, during certain times set by the company. Adaptive Auth Server does that by determining API Client location and current time where that client is. Here, again remote address is required, so that Adaptive Auth Server can calculate current API Client time and run through the time of access rules to determine if the client is matching any of the configured time of access rules.
¶ Browser User Agent Configuration
A User-Agent (also known as UA string) is an alphanumeric string that identifies the ‘agent’ or program making a request to a web server for an asset such as a document, image or web page, in our use case is for RESTful end point most of the time. It is a standard part of web architecture and is passed by all web requests in the HTTP headers.
For Adaptive Auth Server, the User-Agent string is very useful because it gives you information about the software and hardware where API Client runs making the request. You can make important decisions on how to handle web traffic based on the User-Agent string, ranging from simple segmentation and redirection, to more complex content adaptation and device targeting decisions.
The way user-agent rules are evaluated is based on 3 parts that all user-agent must have according to the standard.
- Device
- OS - operating system
- Browser
For example, let's say we have a User-Agent string like this:
Mozilla/5.0 (iPhone; CPU iPhone OS 5_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B179 Safari/7534.48.3
The resulting string that is evaluated according to the 3 parts mentioned before is:
"iPhone / iOS 5.1 / Mobile Safari 5.1"
Having that said, our rule to evaluate user agents for Iphones and Operating Systems like iOS will be:
iPhone / iOS 5.1 / Mobile Safari 5.1
Another example will be for a Google Chrome browser:
User-Agent string:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
Rule that needs to be entered is:
PC / Mac OS X 10.15.7 / Chrome 132.0.0
¶ Similarity Ratio Configuration
This particular section specifies the ratio or similarity percentage to be allowd when matching API Client location or user-agent rules.
To do that Adaptive Auth uses and sequence matcher algorithm, the basic algorithm predates, and is a little fancier than, an algorithm published in the late 1980’s by Ratcliff and Obershelp under the hyperbolic name “gestalt pattern matching.”
For example, the ratio calculated for the next 2 words is 75%:
>>> ratio = similarity('Atlanta', 'Atlantics')
>>> print(ratio)
0.75
According to the similarity ratio configuration we have in the image, when Adaptive Auth Server evaluates these 2 strings, the ratio is bellow the ratio accepted or allowed by the Adaptive Auth Server and by consequence either location and/or user-agent rules might not we the weight that counts for the final score towars the API Client evaluation and validation.
Another example that counts upon user-agent validation is the next one that after calculating similarity ratio it returns 93%
>>> ratio = similarity('Mac OS X 10.15.7', 'Mac OS X 10.15')
>>> print(ratio)
0.93
Be careful about not being too permissive with this configuration because it might address API Providers to open endpoints access to a non desired clients or locations.
¶ Code examples
For code examples and more see here Adaptive Authentication Code Examples