Skip to main content
Feedback

Usage

The connector performs IP allowlisting as follows:

  • Allowlisting by IP range - 123.45.67.0-123.45.67.128

  • Allowlisting by IP list - 123.45.67.0,123.45.67.128

  • Allowlisting by Subnet - 123.45.0.0/16

  • whitelisted_ip_range and whitelisted_ip_list are optional and don't need to be configured together.

  • When only whitelisted_ip_range is configured, then incoming user client IP address must be present in the range specified.

  • When only whitelisted_ip_list is configured, then incoming user client IP address must be present in the IP list specified.

  • When both whitelisted_ip_range and whitelisted_ip_list are configured, then client IP address must be present in either whitelisted_ip_list and whitelisted_ip_list.

  • Introduced new Pre-input configuration keep_client_ip_as_source, which is a boolean flag that is optional.

  • When keep_client_ip_as_source is true, then it returns the IP Address of originating client; and if it is false, then it returns the IP address of nearest proxy to API Management. Whatever IP address it returns depends on this flag; this IP address must be present either in whitelisted_ip_range or in whitelisted_ip_list.

    The current sequence of identifying client IP address is applicable if keep_client_ip_as_source is set as true.

  • IP address configured must be a publicly-recognized IP address (for example: <https://whatismyipaddress.com/>) that is recognized by API Management proxy.

  • Best practice for IP allowlisting (when third-party proxy server is in front of API Management in the API call flow) is to configure the IP address of proxy (for example, Intermediate Node 2) that is closest to API Management stack.

    For example: client/WWW --> Intermediate Node 1 --> Intermediate Node 2 --> Cloud API Management --> Resource API

    For more details on how X-Forwarded-For directive compiles client IP address while traversing through various load balancer and or proxy server, refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For.

Current Sequence of Identifying Client IP Address

The priority sequence logic (shown below) currently supported in this Connector achieves the following:

  • Accurately identifies client IP address in data flow across various systems before it reaches to API Management stack.

  • Designed to identify various factors that might get involved in storing client IP address which may involve chaining.

Priority SequenceHTTP Header NameSequence FlowNotes
1X-Forwarded-For↓Move to next only if client IP is not found in the given header
2Proxy-Client-IP↓Move to next only if client IP is not found in the given header
3WL-Proxy-Client-IP↓Move to next only if client IP is not found in the given header
4HTTP_X_FORWARDED_FOR↓Move to next only if client IP is not found in the given header
5HTTP_X_FORWARDED↓Move to next only if client IP is not found in the given header
6HTTP_X_CLUSTER_CLIENT_IP↓Move to next only if client IP is not found in the given header
7HTTP_CLIENT_IP↓Move to next only if client IP is not found in the given header
8HTTP_FORWARDED_FOR↓Move to next only if client IP is not found in the given header
9HTTP_FORWARDED↓Move to next only if client IP is not found in the given header
10HTTP_VIA↓Move to next only if client IP is not found in the given header
11REMOTE_ADDR↓Move to next only if client IP is not found in the given header
12request.getRemoteAddr()Default. If client IP was not found in any of the HTTP headers above.
note

The current sequence of identifying client IP address is applicable if keep_client_ip_as_source is set as true.

On this Page