Access Rights Policy based on IP Range

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Product: Rosetta
Product Version: 8.1 and newer

Question

How Rosetta checks the IP during delivery using Access Rights Policy based on "IP Range" expression/s ?

Answer

Rosetta until version 8.1 only supports IPv4 in Access Rights Policy "IP Range" field.
Initial IPv6 support was added in Rosetta version 8.2: either IPv4 or IPv6 "IP Range" expressions are supported within the same Access Right Policy.
Rosetta version 8.3 is tentatively planned to have support for combination of IPv4 and IPv6 "IP Range" expressions in the same Access Right Policy.

During entity (IE/REP/FILE) delivery, the relevant Access Rights Policy is checked.
When the Access Rights Policy is based on one or more "IP Range" expressions, Rosetta first checks if the HTTP request contains a header, as configured in "client_ip_header" General Parameter of Rosetta (typically "X-Forwarded-For").

Until Rosetta version 8.1:

If the "client_ip_header" HTTP header (i.e. "X-Forwarded-For") value exists in the delivery request, Rosetta checks if the header's value is a valid IPv4 value (If multiple such headers exist, Rosetta checks the value of such first header).
Then:

If it's a valid IPv4 value, Rosetta compares it with the Access Rights Policy conditions. (More details on how Access Rights work)
If it's not a valid IPv4 value, (like when IPv6 is used, or that the "client_ip_header" header's value is a string of comma delimited IPs, etc), Rosetta uses the REMOTE ADDRESS: (i.e. the first left column in Tomcat access log)
- If it's a valid IPv4 value - Rosetta compares it with the Access Rights Policy conditions. (More details on how Access Rights work)
- If it not a valid IPv4 value - Rosetta declines the request (assuming any other Access Rights Policy expression outcome is false as well)

Example 1

192.168.0.1 "192.168.0.2" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

Assuming the "client_ip_header" is set to "X-Forwarded-For", Rosetta would compare the relevant Access Rights Policy conditions against "192.168.0.2".

Example 2

192.168.0.1 "0:0:0:0:0:0:0:2" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

Assuming the "client_ip_header" is set to "X-Forwarded-For", Rosetta would ignore the non valid IPv4 value and would compare the relevant Access Rights Policy conditions against the remote address value 192.168.0.1.

Example 3

0:0:0:0:0:0:0:2 "-" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

Assuming the "client_ip_header" is set to "X-Forwarded-For" and no value is passed, Rosetta would compare the relevant Access Rights Policy conditions against the remote address "0:0:0:0:0:0:0:2", but since this value is not IPv4 the request would get rejected since Access Rights "IP Range" field support only IPv4.

Rosetta version 8.2 and newer:

If the "client_ip_header" HTTP header (i.e. "X-Forwarded-For") value exist in the delivery request, Rosetta checks if the header's value is a valid IPv4 or IPv6 value (If multiple such headers exist, Rosetta checks the value of such first header).
Then:

If it's a valid IPv4 or IPv6 value, Rosetta compares it with the Access Rights Policy conditions. (More details on how Access Rights work)

Rosetta v8.2.0.x support the same IP version across any "IP Range" expressions of the same Access Rights Policy - i.e. combining IPv4 and IPv6 "IP Range" expressions (in the same or different Group) in the same Access Right Policy is not supported.
Rosetta v8.3 is tentatively planned to have support for combination of IPv4 and IPv6 "IP Range" expressions in the same Access Right Policy.
If it's not a valid IPv4 or IPv6 value, (like when unexpected characters are added by a proxy, etc), then Rosetta checks the HTTP Remote Address (i.e. the first left column as reported by Tomcat access log):
- If it's a valid IPv4 or IPv6 value - Rosetta compares it with the Access Rights Policy conditions. (More details on how Access Rights work)
- If it not a valid value - Rosetta declines the request (assuming any other Access Rights Policy expression outcome is false as well)

Example 4

192.168.0.1 "-" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

0:0:0:0:0:0:0:1 "-" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

Assuming the "client_ip_header" is set to "X-Forwarded-For" but since its value is empty, Rosetta compares the relevant Access Rights Policy conditions against the HTTP Remote Address value (e.g. 192.168.0.1 or 0:0:0:0:0:0:0:1).

Example 5

192.168.0.1 "0:0:0:0:0:0:0:5" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

192.168.0.1 "10.0.0.1" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

Assuming the "client_ip_header" is set to "X-Forwarded-For" and its value is a valid IPv4 (e.g. 10.0.0.1)or IPv6 (e.g. 0:0:0:0:0:0:0:5), Rosetta compares the "X-Forwarded-For" value against the relevant Access Rights Policy.

Example 6

192.168.0.1 "10.0.0.1," - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

192.168.0.1 "0:0:0:0:0:0:0:6," - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

Assuming the "client_ip_header" is set to "X-Forwarded-For" and its value is not a valid IPv4 or IPv6 (e.g. due to an unexpected postfix of the comma character) Rosetta checks the HTTP Remote Address (e.g. 192.168.0.1) against the relevant Access Rights Policy.

Tomcat, bundled out-of-the-box with Rosetta, may identically log multiple "X-Forwarded-For" HTTP headers and also single "X-Forwarded-For" header containing a delimited multi-value string.
For example, in the scenario "X-Forwarded-For" header is either:

Two different headers with different values like:
- 0:0:0:0:0:0:0:1
- 0:0:0:0:0:0:0:2
Single header with comma and space delimited multi-values: 0:0:0:0:0:0:0:1, 0:0:0:0:0:0:0:2

In both cases, tomcats may log such request identical in the access log, e.g.:

192.168.0.1 "0:0:0:0:0:0:0:1, 0:0:0:0:0:0:0:2" - - [22/Aug/2023:01:46:29 +0200] GET /delivery/...

However, Rosetta treats scenario B value (i.e. a delimited string "X-Forwarded-For" value) as an invalid IP value.

Article last edited: 09-Apr-2025