This filter is deprecated, as functionality is reproduced in the IP User filter. This filter will be removed as of v220.127.116.11.
The IP Identity filter can introspect a requests source IP and set the X-PP-User and X-PP-Groups headers accordingly. The filter will first check the X-Forwarded-For header to see if the client address has been specified there. If not, the the remote IP address is obtained from the HTTP request.
General filter information
Filter name: ip-identity
Filter configuration: ip-identity.cfg.xml
Released: version 1.1.2
Required headers: The IP Identity filter has no required request headers.
Required preceding filters: The IP Identity filter has no required preceding filters.
Standard filter order: If you are using other filters in your system model configuration, refer to the standard filter order table to determine where to place the IP Identity filter.
The ip-identity.cfg.xml file contains the following elements and attributes. Add the filter to your Repose deployment through the system model configuration.
|<ip-identity>||-||Required||Specifies the sub-elements and attributes to define your IP identity mapping configuration.|| |
|<quality>||-||Optional||Defines quality assigned to user using the incoming source IP.||Added in version 2.0.0|
|<white-list>|| ||Optional||Lists the IP addresses that will be given a group of IP_Super. The whitelist contains a list of ip-address that you do not want to rate limit.||Added in version 2.0.0|
|quality||Required if using whitelist.||Defines quality used for addresses in the whitelist.|| |
|<ip-address>||-||Required||Contains an explicit IP address or an IP network specified using CIDR notation (e.g. 192.168.0.0/16).|| |
Rate limiting by IP configuration
To rate limit by IP, use the IP Identity filter to add the X-PP-User and X-PP-Groups header values. The IP Identity filter only identifies requests by the originating IP, and the Rate Limiting filter only rate-limits based on the X-PP-User and X-PP-Groups headers. Therefore, you will need to use both filters to rate limit by IP.
When the IP Identity filter receives a request, it will add the X-PP-User and X-PP-Groups headers to the request. The X-PP-User will be given the value of the originating IP. The X-PP-Groups header will be given the value of IP_Standard unless you configure the whitelist in the IP User filter. If you have configured the whitelist, the X-PP-Groups will be given the value of IP_Super.
The Rate Limiting filter makes use of the X-PP-User and the X-PP-Groups headers to determine and keep track of a users rate-limits. Because the Rate Limiting filter cannot identify users, it expects the X-PP-User and X-PP-Groups header to be present when it receives a request. If X-PP-User is not present, it will return a 401 status code because it cannot determine who the requester is. If the X-PP-User is present, it will look for the X-PP-Groups header. If the X-PP-Groups header is not present, the Rate Limiting filter will use the default rate-limit group configured in the rate-limiting.cfg.xml file.
The following example shows a section of a configuration for the IP User filter and the Rate Limiting filter set up for rate limiting by IP.
IP USER FILTER
<user-header name="X-PP-User" quality="0.4"/>
RATE LIMITING FILTER
<limit-group id="customer-limits" groups="IP_STANDARD" default="true">
<limit uri="/service/*" uri-regex="/.*" http-methods="GET" unit="SECOND" value="1"/>
<limit uri="/service/*" uri-regex="/.*" http-methods="DELETE" unit="MINUTE" value="5"/>
<limit-group id="admin-limits" groups="IP_SUPER">
<limit uri="/service/admin/*" uri-regex="/.*" http-methods="GET POST PUT DELETE" unit="SECOND" value="10"/>
Return codes and conditions
This filter does not return specific response codes. The request will simply pass through to the next filter or to the origin service.
- X-PP-User will be set to the source IP.
- X-PP-Groups will be set to IP_Standard or IP_Super.