Add page for globally defining IP ranges

1 Initial Problem

In association with Test: Increase flexibility in specification of IP address restrictions, we feel that IP address range restrictions for tests were an incredible addition. However, this feature in its current implementation is not really accessible to non-technically versed staff. In addition, assignment of allowed clients by IP address (range) is tedious, error-prone and inflexible (e.g. when a new computer is added to an exam room).

2 Conceptual Summary

This feature request adds the concept of "IP address definitons" to ILIAS. IP address definitions are ILIAS objects describing zero or more IP address ranges or individual IP addresses.

In order to accomplish this, the ILIAS Administration area is extended by addition of a new page with allows for the global definition of IP address definitions. By managing these definitions in the ILIAS Administration UI, the known ILIAS method of access control – RBAC with users and groups – is utilized for controlling who is allowed to define IP address definitions.

IP address definitions are specified by a unique name (user-defined string), a description (user-defined string) and an array of IP address ranges. IP address ranges herein are simple data structures containing one or two strings: One string for the minimum IP address of a range, one optional string for the maximum IP address of a range. By making the maximum IP address optional, singular IP address restrictions are also possible.

It is currently still undecided whether this feature should be located under "Organization" or "Users and Roles" within the Administration menu. "Organization" would make sense as this feature can be used to represent the network layout of physical rooms within an institution, whilst "Users and Roles" would make sense as this feature covers access control settings. Comments regarding this choice are welcome in the Discussion section below.

In order to integrate this new component into the existing ILIAS codebase, the following adjustments are performed:

IP address definitions are directly referenced within both components by their reference IDs. As a result, editing an IP address definition in the Administration settings will directly and immediately affect all objects (= tests and users) using this IP address definition. This choice is intentional, as potential changes in the network architecture of an institution are immediately propagated to all dependant objects.

This feature requires new icons.

2.1 Non-goals and end of scope

While export and import of IP address definitions within the Administration UI are supported, potential linkages to dependant components will intentionally not be implemented. As a result, the import of tests and users will need to be adjusted in order to only resolve IP address definitions if an test export object originates from the same ILIAS installation. This decision was made both to reduce technical complexity, but also to prevent inadvertently granting access to a test.

As Test: Increase flexibility in specification of IP address restrictions will remove the ability of inserting ranges directly into the test access settings, this feature will also include migration methods for existing IP address range settings. Existing IP address ranges will then be converted to IP address definitions with random names. We understand that implementation is inherently a breaking change and are open for discussion on other method to properly handle this.

2.2 Prospects

Implementation of this feature request will allow other components to leverage the access control features provided by it, which might prove valuable in access control decisions where RBAC is currently available.

2.3 Relation to other Feature Requests

This feature depends on and shall be implemented together with Test: Increase flexibility in specification of IP address restrictions.

3 User Interface Modifications

3.1 List of Affected Views

This feature request will add the following views:

This feature request will update the following views:

No views will be removed by this feature request.

3.2 User Interface Details

No user interface elements need to be added, modified or removed to the set of existing Kitchen Sink elements.

A new menu item "IP Address Definitions" will be added to the Administration menu (see below for the discussion on placement). This menu item will lead to a new page, named "IP Address Definitions". On this page, the created IP Address Definitions will be listed, and options for creation/deletion of them will be available. The following tabs will be present:

IP address definitions can be managed/imported using the "Manage" button, which otherwise behaves as it does with other common components.

Another new page will be created for managing individual IP address definitions directly, accessible by clicking on a created IP address definition. This page will display a table with all IP address ranges associated with this IP address definition (containing a dropdown to allow for editing/deleting IP address ranges). The following tabs will be present (the screenshot is out of date!):

When clicking the "Add new Object" button, a new modal for creating/editing IP Address Ranges will be shown. This modal contains two text inputs for the minimum and maximum IP address of the IP address range.

To integrate this feature into the Test component, the current two text inputs for minimum and maximum IP addresses of a range will be replaced by a tag input field (in accordance with Test: Increase flexibility in specification of IP address restrictions). This tag input field will support the values listed in Test: Increase flexibility in specification of IP address restrictions, but will also support adding IP address definitions by name. Furthermore, async-autocomplete will be added to this Tag Input in order to allow for searching of all IP address definitions that are currently set to "online".
The modal controlling the allowed IP address range of an individual participant will also be adjusted as mentioned previously.

3.3 New User Interface Concepts

No new user interface concepts are introduced.

3.4 Accessibility Implications

No accessibility implications are apparent. The availability of names instead of decimal or hexadecimal numbers, with separators, might marginally improve usability and even accessibility for some scenarios; however this is neither a motivation nor a cricical aspect of this Feature Request.

4 Additional Information

4.1 Involved Authorities

For the Administration component:

Authorities for this new component need to be found (see below).

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

This feature request will mainly introduce the following two new ILIAS object types:

In order to store the data pertaining to IP address ranges, a new table ("ipaa_data") with the following list of columns will be added to the database:

IP address ranges can be retrieved, modified and deleted using a new "IP address range repository", which can be freely instantiated using the reference ID of an IP address definition. Testing whether or not a client IP is within the range(s) defined by an IP address definition will be handled by a method within the IP address range repository. If other objects wish to use this functionality, the individual objects are responsible for storing the reference ID of the used IP address definition(s), which they can then use to instantiate the IP address range repository and thereby check whether a given IP address is within the ranges defined in the given IP address definition.

Furthermore, new Data objects (for IP addresses, IP address ranges and IP subnets) will be added to the Data component, which can be instantiated freely and provide functionality for checking the validity of each. Instantiation will be made possible using an included factory, and can therefore be called like this:

$df = <your data factory instance>;
$ip = $df->ip()->address("192.168.178.1"); // this will throw an error if the provided string is not a valid IP(v4/v6) address
$ip_valid = IpAddress::isValid("192.168.178.1"); // this will return a boolean value depending on whether the input is a valid IP(v4/v6) address

4.3 Privacy

No personal data needs to be stored. Potentially, IP addresses of specific computers which are tied to or strongly associated with people (e.g. office computers on people’s desks) could be stored in this system, but that is not the primary target of this feature suggestion. Such a use might have privacy implications, but their consideration is out of scope for this Feature Request and is appropriate in platform or organizational rules for people administrating the installation or Tests.

4.4 Security

This feature could potentially be used in order to directly associate the IP addresses of rooms with their geographic position. It is hard to believe that somebody wishing to execute such a pinpointed targeted attack would need to rely on this feature to obtain said information.

(When implemented correctly,) this feature does not open up ILIAS to new security issues.

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers: Meißner, Bastian [bmeissner.ur].

This Feature Request has been prepared in association with Roeser, Nico [nicoroeser].

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

The University of Regensburg would be interested in delivering (programming, contributing unit tests, suggesting test cases, language file changes for some languages) this themselves if/when this feature suggestion gets approved.

This feature request is looking for authorities for the new component. If you are interested, please get in touch. The University of Regensburg is not going to assume any of the authorities associated with the feature described in this feature request.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.