Feature Wiki

Information about planned and released features

Tabs

Unbundling of Admin Permissions

Page Overview

[Hide]

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

The permission settings in the administration can easily lead to misconfiguration if roles should only use parts of the administration.

Current Situation

  • A clickable entry in the administration menu (admin node) requires an RBAC node as a child of the system folder. The READ and WRITE permissions must be defined for the admin node.
  • For the general visibility of the administration menu, the system folder is tested for VISIBLE:
    \ILIAS\GlobalScreen\Helper\BasicAccessCheckClosures::hasAdministrationAccess
  • For an admin node to appear in the menu, a user must have both VISIBLE and READ on it:
    \ILIAS\Administration\AdministrationMainBarProvider::getStaticSubItems
  • The GUI of an admin node corresponds to the GUI of its RBAC object. It is called via ilAdministrationGUI as the base class. It checks whether the user has VISIBLE or READ for the system folder.
  • All other permissions relating to an admin node must be checked in its own GUI. To do this, ilRbacSystem must be used instead of ilAccess, otherwise the READ on the path would also be tested when checking for READ, which does not have to be the case for the system folder.

Relevant Jour Fix decisions

Administration nodes must offer a read permission and a read-only view should be implemented (e.g. forms should not display save buttons). Visible permissions should be abandonded from administration nodes.

https://docu.ilias.de/go/wiki/wpage_3452_1357, chap. 2.

The ilAdministrationGUI should allow the access for users with only read access (not visible) to open those links. Currently it does not allow this by checking for visible rights in the execute command.

[…]

JourFixe, ILIAS [jourfixe], August 28, 2017: We highly appreciate the suggestion to have an easy access to the Kitchen Sink documentation. We schedule this feature for 5.3. We only raise an error in the executeCommand function if neither visible nor read permission is given.

https://docu.ilias.de/go/wiki/wpage_4681_1357

Users with the RBAC Permissions "visible" and "read" and the Position Permission "Edit User Accounts" are allowed to:

  • Edit/Manage user account of "their" OrgUnits. Other User Accounts will be filtered
  • The Export of user accounts is filtered
  • The "Letter Filter" wil be filtered

The following features will be resticted or disabled:

  • It is not possible to change any role assignments
  • The "Advanced User Search" will be disabled.
  • Adding User Accounts or Importing User Accounts will be disabled
  • The "User List" for the "Multi-Actions" "All Objects" are restricted to the user account which are allowed to be mangaged by OrgUnit-Permissions.

[…]

We highly appreciate this suggestion and schedule the feature for 6.0. We would like to clarify that this feature request does not include support of positions in the local administration.

https://docu.ilias.de/go/wiki/wpage_5905_1357

The JourFix decision from 2015 was never fully implemented. The READ and VISIBLE tabs are available for all admin nodes and are tested for an entry in the menu.

Problems

The system folder is also the admin node for “General settings”. Its permissions are used for different purposes:

  • VISIBLE displays the administration menu
  • VISIBLE or READ allows the GUIs of admin nodes to be called up
  • VISIBLE and READ displays “General settings” in the menu

This combination is confusing. To give users access to other admin nodes, VISIBLE must be set under “General settings”. READ is additionally required for the general settings.

In the admin node ILIAS accounts, the READ permission of the admin node causes all accounts to be displayed. However, it must also be set for the node to appear in the menu. Then, however, no restricted view of the accounts of your own organizational unit can be given.

2 Conceptual Summary

2.1 Option 1: Unbundling of Permissions

  • The system folder gets a new “Administration menu is visible” permission. It is copied from the VISIBLE permission during the ILIAS update. This permission is used to display the administration menu. The VISIBLE permission then only refers to the system node itself. The title when calling up the node is adapted to the “General settings” menu entry.
  • To enter the GUI of an admin node in the admin menu, its VISIBLE permission is sufficient.
  • When the GUI of an admin node is called up, the permissions of the system folder are no longer checked. The GUI must check the permissions of its own node. Generally, it will require READ permission for all commands. In the case of user accounts, the accounts displayed are filtered more finely according to READ for all accounts and or by organizational unit for selected accounts.

This variant requires relatively few changes. If the have previously relied on the checked VISIBLE of the system node for display, they must now check their own permission. But this should be done anyhow to distinct between READ and WRITE.

2.2 Option 2: Unbundling of the System Folder

The SystemFolder component component and its RBAC node 'adm' combine several functions:

  • Parent container for all RBAC nodes of administration entries, but without being used for the permission check via ilAccess
  • General settings (basic settings, installation header, contact information)
  • Server settings (installation status, server info, Java server)
  • Tab for cron jobs (with jump to the GUI in the cron component)
  • Benchmarks

The general settings, server settings and benchmarks can be separated into their own components with separate authorities. Whey will get ther own RBAC nodes as childs of the system folder.

The system folder then only has the function of being the parent of all admin nodes.

  • Its VSIBLE permission is checked to display the administration menu.
  • To enter the GUI of an admin node in the admin menu, its VISIBLE permission is sufficient.
  • In the GUIs of the admin nodes, the permissions are checked via ilAccess. This means that the READ permission of the system folder is a prerequisite for the READ permission of the ADMIN node.

The system folder has its own “Administration access” entry in the Admin menu, in which only these permissons can be set.

3 User Interface Modifications

3.1 List of Affected Views

  • … { Please list titles of all views (screens) of ILIAS that should be modified, newly introduced or removed. }

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

  • Authority to Sign off on Conceptual Changes: {Please add related profile link of this person}
  • Authority to Sign off Code Changes: {Please add related profile link of this person}

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:  {Please add related profile link of this person}

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}

  • {Test case number linked to Testrail} : {test case title}

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

Last edited: 4. Apr 2025, 09:00, Neumann, Fred [fneumann]