Flexible and inheritable IP restrictions at course level

If you need any help in filling out this wiki page, please visit our ILIAS Community FAQ. And please complete the metadata information in the right column after having created the page.

1 Initial Problem

Restricting access to tests using IP addresses is a crucial tool for ensuring exam conditions. However, the current implementation is inadequate on two levels:
Lack of flexibility: Only a single, contiguous IP address range (defined by a start and end IP) can be configured in the test settings. This is impractical for common scenarios such as exams at distributed locations or in segmented networks.
Lack of inheritance: Configuration is done exclusively at the level of individual test objects. For courses that include multiple tests, IP restrictions must be maintained individually and redundantly for each test. This significantly increases administrative effort and the likelihood of errors. The workaround of creating separate test duplicates for each IP range is inefficient. There is no central, flexible, and inheritable configuration option at the course level.

2 Conceptual Summary

We propose expanding the core functionality with a flexible and inheritable system for IP restrictions at the course level. The concept is based on two pillars:
Flexible IP rules at course level: The rigid entry of start and end IP addresses is replaced by a dynamic list of IP rules that is managed directly in the course settings. This allows the definition of any number of independent IP addresses, ranges, and subnets (CIDR notation).
Inheritance logic for test objects: IP restrictions defined in a course are automatically inherited by all test objects contained therein, overwriting any existing individual settings. If no restriction is active at the course level, the specific settings of the respective test apply. This combination creates a centralized, powerful, and easy-to-manage solution that minimizes administrative effort and ensures consistency within a course.

2.1 Use Cases

Central exam control: An administrator configures the IP networks of the associated computer rooms (134.76.10.0/24, 134.76.12.0/24) for their course. All tests within this course automatically adopt this setting, which ensures a uniform and secure exam environment.
Exception for individual tests: A course has a general IP restriction for in-person exams. However, a special online self-test should be accessible without this restriction. Since the test is not subject to a course-wide rule (if inheritance is disabled or no rule is set), its own (non-existent) restriction applies.
Hybrid scenarios: Access to the campus IP ranges is restricted for a course. For a specific test, a single external IP is additionally activated for a person in remote supervision (this should be possible in the test settings if there is no inheritance from the course).

2.2 Details of the procedure

5.1. Procedure (from the perspective of the administrators)

A) Configuration in the course:

1. A person with the appropriate rights navigates to the course settings.
2. There they will find a new section, e.g. under “Availability,” with the title “IP restriction.”
3. After activating the functionality (e.g., via a checkbox), an interactive list for managing the IP rules appears.
4. An “Add IP rule” button displays a new input line.
5. In this line, the rule type can be selected via a selection menu:
   - Single IP: A text field for entering the address.
   - IP range: Two text fields (“From” and “To”).
   - CIDR subnet: A text field for entering the network address (e.g., 192.168.2.0/24).
6. Each rule added is displayed as a line in the list and can be deleted again using a “Remove” button.
7. The system validates the entries for correct IP formats.
8. The rule list is applied when the course settings are saved.

B) Behavior in the test:

1. In the test settings under “Access,” a note is added to the section for IP restrictions.
2. If the test is in a course with active IP restrictions, a non-editable message is displayed: “The IP restrictions of the parent course apply to this test.” The course-wide rules are listed for transparency.
3. The option to define your own IP rules in the test is disabled in this case.
4. If the test is not in a course or if the course has no IP restriction, the form behaves as usual (but should also be converted to the new, flexible input format).

5.2. Technical points of reference

Course configuration: The UI for the IP rules must be added to the course GUI class ilObjCourseGUI (presumably in the initEditForm method). The rules should be stored in a structured format (e.g., as JSON in a new or existing database table for course settings).
Test configuration: The class ILIAS\Test\Settings\MainSettings\SettingsAccess must be adapted. The method getInputIpRange must check whether there is inheritance from the course. If so, the input option is deactivated and an information text is displayed. If not, the new, flexible UI component for rule definition should also be used here.
Access check: The logic that checks access to a test must be extended. It must first query whether the test is in a course and whether this course has active IP restrictions. If so, these rules are used to validate the IP address of the test participants. Otherwise, the test's own rules are used.

2.3 Mockup

A detailed mockup can be created if required. The core idea is a list in the course settings, where each line represents an IP rule with type selection, the necessary input fields, and a “Remove” button. An “Add” button below the list allows new rules to be created.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

{ For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour. }

3.3 New User Interface Concepts

{ If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this. }

3.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

4 Additional Information

4.1 Involved Authorities

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

4.2 Technical Aspects

{ Necessary technical information have to be provided here, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

4.3 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

4.4 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  Holger Markus holger.markus@uni-goettingen.de, Andreas Zahn andreas.zahn@uni-goettingen.de

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'.

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}.