Show Advanced KnowledgeHide Advanced Knowledge

Maintenance Mode Enhancement

This page and feature request seems to be heavily outdated. Please contact Klees, Richard [rklees] if you want to work on this idea.

1 Description

ILIAS can be configured via setup to display a maintenance screen. This allows administrators to perform code changes and configuration of server, database, ini-files, and ILIAS-setup. It is however not possible to access the ILIAS-administration or ILIAS itself.
 

1.1 Purpose

The maintenance mode should be enhanced in a way to allow access to ILIAS administration and ILIAS itself for a privileged group of users (admins/testers/...). All non-privileged users are of course to be locked out by the maintenance screen!
The enhancement shoud be

• robust: The maintenance mode must be as robust as possible: In case ILIAS is broken on some installation (no db-connection, broken code or configuration, ...) the maintenance mode should still be operable. The maintenance mode and privileged access must therefore rely on as little ILIAS-functionality as possible!
• configurable: For security and other reasons it must be possible to configure and deactivate the privileged access.
• flexible: Privileged access should be granted individually - not group-wise!
• generic: The priviledged access should be as compatible with existing SSO-implementations as possible. (There is no SSO-framework - every implementation is different!!).
• simple: Because simple is beautyful (and cheap). ;-)

1.2 Variants

A IP-Mask

• Definition of comma-separated IP-List (with wild-cards) to allow access
• Additional hint: "Your IP is ......"
• Save the IP-Mask in ILIAS-INI-File

Advantage: VERY robust, generic and simple (+secure)
Disadvantage: Not flexible, because many different users can share one IP-Adress
 
B Access-Code

• Randomly generated Access Code to be transferred by GET-Parameter
• Save the code in ILIAS-INI-File

Note: We don't want to display a form like "please enter your secret access code here" to avoid curiosity and possible brute-force attacks (in case the maintenance mode is used to work around a security issue)
 
B1 Save priviledged access in session
Note: The ILIAS-Session-handling is already very complex - sessions may e.g. be closed an re-initiliased on some occassions.Disadvantage: => Not very simple and robust!
 
B2 Save priviledged access in cookie
Advantage: Independent of ILIAS-functionality -> very simple, generic and robust! This might also work with very different SSO-implementations if the cookie is set (via GET-Parameter) before using SSO!
 
B3 Save priviledged access in URLs
Note: There is no general ILIAS-function to generate URLs => It would be neccessary to rely on something like JavaScript to insert the GET-Parameter in all URLs.
Disadvantage: Not very robust and just very bad style! :-)

2 Status

• Scheduled for Release: Not scheduled yet
• Funding: Required / Partly funded by / Funded by ...
• Development: Feature is to be developed by

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: kiegel@qualitus.de

4 Discussion

We (Qualitus / Databay) favour Variant B2: Access Codes + Cookie. We think, this way it could even become part of ILIAS 4.3 - as it involves only minor changes. ~Kiegel, 02.05.2012

Clarification: Our idea is to save the "access code" rather than a flag "priviledged access". E.g.: In B2 the cookie would store the access code (after the first request with access code in GET-Parameter). ~Kiegel, 02.05.2012

Alex 4 May 2012: B2 sounds obscure to me (other variants, too). It would fit more into existing concepts, when just access for ILIAS administrators is enabled and allowed. This topic will definitely need some discussion by core developers.
 
There seems to be a misunderstanding what "could even become part of ILIAS 4.3". This is a new feature and we are now feature freezed for 4.3.

Matthias Kunkel, 04 May 2012: I have also problems to understand all of these approaches.
 
AFAIK, the ILIAS RBAC works also in maintenance mode and can be used for permission control, am I right? Therefore we could either allow all members of global role "Administrator" or all members of a local administration role "Privileged access" to enter ILIAS even in maintenance mode.
 
The only thing you need is "another" login screen for those privileged users - because the existing login screen is disabled. This "other login screen" might be hidden behind a redirect link that can be defined in the administration. Even if this link is known by unauthorized persons, the ILIAS RBAC will prevent that such persons enter ILIAS when trying to login.
 
And as Alexander already mentioned: feature freeze for 4.3 was at March 31! ;-)

Kiegel, 07 May 2012: Thank's for your input.
 
We didn't consider dependencies on RBAC (and other ILIAS functions) to assure the maintenance mode to work even if ILIAS/RBAC is broken!
=> However, that wouldn't be a problem with the proposal of alex and matthias to show a second/hidden login screen. The proposal seems to be reasonable (not as flexible but definitely more secure). :-)
 
BTW: Is this topic a part of "Setup" or "Login & Authentication" or both?
 
UPDATE (08 May 12): We discussed your proposal and concluded that it doesn't suit our needs very well. We need to grant access for individual users - regardless of their ILIAS role - for the purpose of testing during maintenance mode. Certain testcases rely on different ILIAS roles (e.g. function X is not available for users with role Y)! Thus, we cannot bind the priviledged access to certain roles. A second (hidden) login screen without any check would work in principle, but is not what we want and we think, it would'nt work with most SSO-implementations. We therefore still favor variant B2, which is more flexible and should work with almost every SSO-implementation.

Alex 9 May 2012: I have the feeling that I misunderstood, what you are planning to do. Colin, you are writing a lot on non-functional needs like security, robustness and so on. But what is this maintenance mode from a functional point of view at all? Your mock-up shows how to activate it. But what happens, when the user accesses this maintenance URL? On the one hand you are writing that the mode should make the ILIAS administration and ILIAS itself available to users. On the other hand, you write that the mode should work, even if ILIAS/RBAC is broken. That doesn't fit together well for me.
 
What functionality should be offered by the maintenance mode exactly? Please write down some use cases.

Kiegel 09 May 2012:
 
Use Case 1: Downtime during a release
New code is to be installed on an existing ILIAS-Installation.
 
Use Case 2: Downtime due to a major bug
A bug occurs on an existing ILIAS-Installation (security issue, broken DB connection, corrupt data, ...).
 
=> In both cases we need to take the installation offline for end-users. On the other hand, we must be able to configure and test it, if we want to. Testing can involve possibly every ILIAS-role depending on the use case. E.g.: If the relevant bug reads "standard users are able to gain admin rights", you clearly cannot test that with an admin account.
 
--
 
The maintenance-URL (variant B2) will lead any user to the Standard-ILIAS-Login-Screen (nothing else). However the maintenance-URL will carry a secret random parameter to circumvent the maintenance mode (which would replace the login screen otherwise). The secret parameter is then stored in a browser-cookie to circumvent the maintenance mode on any further page request (i.e. after login or after subsequent SSO). The user who followed the maintenance-URL will be able to use ILIAS as if the maintenance-mode was disabled.

Alex 9 Mai 2012: Ok, now I am beginning to understand. Why not temporary putting a simple .htaccess file into the installation that restricts access, e.g. for qualitus staff only!?

Kiegel 14. Mai 2012: That would be almost it! The only disadvantage I can see is: Everyone will see the password dialog and some users may be irritated.. => I think, it's not as comfortable, but it would work! We might still want to program variant B2 and offer it for trunk integration. :-)

Alex 23 Mai 2012: You can do all kind of things with .htaccess, e.g. presenting the usual ILIAS for a certain IP number range (qualitus staff) and redirect to any static maintenance html page that you setup for everyone else. No need to present password dialogs "for everyone".

Kiegel 01 June 2012: The feature has been programmed as described in variant B2 - we would like to offer it for trunk integration.
=> Would it be a good idea to make the maintenance page look nicer (i.e. using ILIAS skins and Templates)? Or would it be better to keep it simple and stay with static html in case the ILIAS installation is terribly broken??..

JF 11 June 2012: We need to discuss this feature with the developer who implemented it before deciding if it should be part of 4.4.

5 Follow-Up