Add page for globally defining IP ranges

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

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 named IP address ranges to ILIAS.

The ILIAS Administration area is extended by addition of a new page which allows for the global definition of IP address ranges with their associated custom names. IP address ranges are specified in the same ways as explained in Test: Increase flexibility in specification of IP address restrictions. Names are user-defined strings. A side effect of managing these definitions in the ILIAS Administration UI is that the known ILIAS method of access control – RBAC with users and groups – is effective for controlling who is allowed to define named IP ranges.

It is open to discussion where in the Administration the new functionality should be positioned. Within “Test and Assessment” is an obvious option; within “Users and Roles” makes sense, too, as these cover access control settings. Depending on further plans (see below), one way or the other may be preferred. Comments regarding this choice are welcome in the Discussion section below.

The IP Range option within the Test settings is extended to also allow selection of such IP address range names that are globally defined in the Administration. This makes the configuration within Tests easier to understand and makes configuration mistakes less likely. The existing options to not use names, but enter IP addresses in other forms, as defined in Test: Increase flexibility in specification of IP address restrictions, stay available and complement the configuration possibilities within the Test.

While an IP Range is associated with a Test by name, editing this IP Range in the Administration will (immediately) indirectly affect the Test. (On purpose. This makes it easy for people who configure Tests to decide whether they like to force a certain IP address or whether they like to force access from some certain object that carries semantic meaning, e.g. one of the “Library Computers” or a computer in “Exam Room A”.) Named IP Ranges may consist of zero to many IP addresses; particularly a single IP address is allowed. (It may make sense to have empty named IP Ranges while sets of computers or rooms are restructured. This ensures that no reconfiguration of Tests is required during the period when the named IP Range is empty. This point is open for discussion, but from a administrative/technical standpoint we see more value in allowing empty named IP Ranges.)

2.1 Non-goals and end of scope

It is currently not planned to allow for the export or import of named IP ranges within the Administration UI. (Direct database access might be an option for administrative staff.) If export and import should be implemented, they could be similar to the respective functions in the User Administration. If you think import/export functionality is required or a good extension, please say so in the Discussion section below.

There is no plan to migrate existing IP Range settings within Tests to named IP ranges as specified in this Feature Request. There is also no strict need to, because existing Test settings remain usable. While shifting from unnamed IP Ranges specified in a Test to named IP ranges may be beneficial in many cases for institutions using ILIAS, it needs a case-by-case decision and thereby is a process to be executed manually or with manual input.

It is not a goal of this Feature Request to connect named IP ranges to other objects but Tests in ILIAS (though it may be useful groundwork, see the following subsection).

2.2 Prospects

Implementation of this Feature Request might be a valuable first step for using IP address ranges (named or without names) as one criterium in access control decisions, in places where RBAC is currently available.

2.3 Relation to other Feature Requests

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

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

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

The proposed interface in the ILIAS Administration consists of one Table (Base, see Kitchen Sink documentation) that allows for the following functionality:

Furthermore, a new (modal) view is necessary in order to add/edit entries. This is accomplished in a form using a text input field, as well as a tag input field.

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

No new user interface concepts are introduced.

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

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

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

The newly created entries need to be stored in the database. The obvious solution is to add one table with an identifier as primary key, a unique(?; TODO) string as name, a string for the IP address range (comma-separated IP address definitions). Storing the IP range as string makes sense as this a) mirrors existing logic used within the Test for this functionality, and b) the options for defining IP addresses require a small amount of parsing anyway, which is not very heavy on resouces (in particular, computing time).

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

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

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

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: Bastian @simple_oaktree

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) this themselves if/when this feature suggestion gets approved.

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