authelia/docs/content/roadmap/active/dashboard-control-panel-and-cli-for-admins.md

title	description	summary	date	draft	images	weight	toc	aliases	seo
Dashboard / Control Panel and CLI for Administrators	Authelia Administrator Dashboard.	A dashboard or control panel for administrators to adjust system settings is easily one of the most impactful features we can implement.	2024-03-21T18:25:55+11:00	false		245	true	/r/admin-dashboard	title description canonical noindex false

Adding a way for administrators to dynamically interface with Authelia is one of the more anticipated features by users, this article describes ideas about this feature some of which are certain to be implemented and some which may not end up being implemented. Effectively we'd like to be able to optionally give administrators the ability to dynamically control aspects of Authelia while it's running, either via a CLI or via a UI.

This feature will pave the way to adding lots of useful administrator facing features. It will require in database settings storage as well as some minimal traditional settings via files or environment variables once the feature reaches the theoretical ideal state.

This feature should not be confused with the Dashboard / Control Panel for Users which is the dashboard for the user self-managing their own settings, as this feature is for managing the system settings instead of the user settings.

Broad Concepts: Optional, Explicit, and Modular

This general idea is about making it as secure and flexible as possible. Reasonably in any security solution like Authelia administrators should have to explicitly and deliberately enable dynamic controls like this. Defaulting to a static configuration allowing mitigation against potential dynamic configuration vulnerabilities. In addition a lot of users love Authelia for the declarative configuration it already has so we don't want to take that away from them.

Another key aspect that we feel a feature like this must have is the ability to add additional mitigations to this like an external firewall that only allows certain network addresses or ZTNA identities to access. To that end we ideally will not only allow configuring Authelia without the dynamic configuration but also allow:

• Control via a CLI either additionally or exclusively
• Control via a UI either:
  • On the same port as the portal
  • On a different port from the portal
  • In a separate process and/or host entirely

In addition to this feature we want to ensure the admin UI is invisible to the normal user so there is no indication if it is or is not enabled, and even make it possible that it can be configured in a way where a person with a compromised admin account will not know they are an admin or that any admin UI exists. This can realistically be achieved by configuration similar to the example below.

server:
  address: 'tcp://:{{< sitevar name="port" nojs="9091" >}}'

administration:
  ## Explicitly enable Dynamic Configuration, either via CLI only or CLI and UI via enable_ui.
  enable: false

  ## Explicitly enable the Admin UI on this Authelia instance. If 'enable' is configured another process could also be
  ## separately configured with this enabled.
  enable_ui: false

  ## Configure the listener address for the UI. If it's exactly the same host and port component as above with a
  ## different path, listen on the same listener as above. If it's exactly the same, error.
  address: 'tcp://:9092'

  ## URL enabling the button/link in the portal for the UI.
  url: 'https://auth-admin.example.com'

  ## List of users who are allowed to view the admin UI. In addition to the groups.
  users:
    - 'john'

  ## List of groups who are allowed to view the admin UI. In addition to the users.
  groups:
    - 'admins'

Broad Concepts: API

A separate API which is authorized via OAuth 2.0 or user sessions will be an absolute must for this feature at least long term. For example if configured to listen on https://auth.example.com/admin the API should be serviced via https://auth.example.com/admin/api/v1 or similar.

The tokens should realistically be able to be generated with granular access, should require a special scope, and have a particular audience to be considered valid.

Stages

This section represents the stages involved in implementation of this feature. The stages are either in order of implementation due to there being an underlying requirement to implement them in this order, or in their likely order due to how important or difficult to implement they are.

Design Stage

{{< roadmap-status stage="in-progress" >}}

Decide on a design.

Initial Implementation

{{< roadmap-status version="v4.40.0" >}}

Implement the pivotal elements of the design.

Design Element: Segregation

{{< roadmap-status version="v4.40.0" >}}

Allow the admin UI to be run as a separate process, on a different port, and at a different URL to Authelia itself. Alternatively allow it to run as part of the main process and port for minimal configurations.

Session Management

{{< roadmap-status version="v4.40.0" >}}

Manage user sessions for all users.

OpenID Connect 1.0 Client Management

{{< roadmap-status version="v4.40.0" >}}

Manage client registrations via a web frontend.

Access Control Management

{{< roadmap-status >}}

Manage Access Control rules.

User Management

{{< roadmap-status >}}

Manage user accounts with either the internal or LDAP authentication backends. Allow for creation, modification, and deletion.