Add none authentication method to disable web login while preserving internal user functionality

If you need any help in filling out this wiki page, please have a look at the page ’How To Suggest A New Feature’.
You can remove the editing notes (paragraphs in italics) after having created the request (same with this block).
Please don't forget to complete the metadata (‘Status of Feature’) in the right column after having created the page.

1 Summary

Introduce a new authentication method "none" that permanently disables web login for an account while keeping it fully functional for internal purposes such as owning Cron Jobs. Additionally, if no user has the ilias-auth/local method assigned anymore, the local web login form can be hidden entirely. The main goal is to reduce the attack surface for needed local users (like root or cron).

2 Problem Statement

System or technical users (e.g. a "root"-style administrative account)) must currently be assigned an existing authentication method such as ilias-auth/local, even though they are never meant to log in interactively via the web in normal operation mode. This means such accounts always retain a theoretical web login path — protected only by password strength — which unnecessarily increases the attack surface. There is currently no way to explicitly and permanently mark an account as "internal use only," nor to hide the local login form once no account actually relies on it. This forces security aware admins to implement workarounds like "hiding" the web login form, deactivating the root user and creating another cron user with lowest permissions. The latter again is then able to login via the web form, even if it is only used for internal cron purposes.

See also discussion in Mantis

3 Concept

4 User Interface Modifications

4.1 List of Affected Views

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

4.3 New User Interface Concepts

None. This feature reuses existing UI patterns

4.4 Technical Aspects

5 Non-Functional Implications

5.1 Security

No new endpoints are introduced. The feature adds a new auth mode and provider to the existing pluggable auth-provider framework, and extends the existing CLI/cron acceptance check to also accept none. This extension relies on a separation between CLI and web/WebDAV/SOAP contexts that already exists today (the CLI path already special-cases local authentication independently of the standard dispatch) — so no new attack vector is introduced beyond what the current architecture already relies on.

5.2 Privacy

None. This feature does not introduce any new personal data field.

5.3 Accessibility Implications

None. This feature only adds a value to an existing dropdown component and reuses an existing conditional-rendering pattern for the login form. No new UI components or interaction patterns are introduced, so no new accessibility considerations arise.

6 Process Information

6.1 Involved Authorities

6.2 Contact

Person to be contacted in case of questions about the feature or for funding offers: [info@pwurbs.dev]

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

7 Discussion

8 Implementation

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

8.1 Description and Screenshots

{ Description of the final implementation and the changed behaviour in the related components. Please add screenshots to visualise the changes if possible. }

8.2 Test Cases

Test cases completed at {date} by {user}

8.3 Privacy

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

8.4 Approval

Approved at {date} by {user}.