5.4. UMC - Univention Management Console#

This section describes the technical architecture of the Univention Management Console (UMC). For a general overview and its relation to system management, refer to System management.

You find the source code at the following locations:

Every UCS system installs UMC and its dependencies per default. UMC consists of the UMC frontend and the UMC backend. Fig. 5.12 shows the simplified architecture of Univention Management Console and the description thereafter.

../_images/UMC-architecture-simple.svg

Fig. 5.12 Architecture overview of Univention Management Console#

The UMC frontend has the following items:

  • UMC web frontend

  • UMC client

The UMC backend has the following items:

  • Static HTTP server

  • Reverse proxy

  • UMC server

  • UMC modules

The user facing parts of the UMC frontend are the UMC web frontend and the UMC client. Reverse proxy handle and transform the requests and pass them to the UMC server at the backend.

5.4.1. UMC communication#

This section focuses on the communication within UMC. Fig. 5.13 shows the architecture with the communication interfaces HTTP/HTTPS, HTTP, Terminal/SSH. The following sections describe the interfaces.

../_images/UMC-architecture-communication.svg

Fig. 5.13 Architecture of Univention Management Console with communication interfaces#

HTTP/HTTPS in UMC#

The user interacts with the UMC web frontend in their web browser. The UMC web frontend communicates through HTTP/HTTPS with the UMC backend. The Reverse proxy receives requests, handles SSL/TLS, and forwards the requests through HTTP to the UMC server.

Terminal and SSH in UMC#

The UMC client communicates with UMC backend through HTTPS. Administrators use UMC through the UMC web frontend or through specific command-line tools.

Caution

Although UMC offers a Command line through Terminal/SSH, only software developers use the interface for example for software testing. Interaction with the interface requires knowledge about the internals of UMC modules.

5.4.2. Authentication#

UMC provides the web and authentication interface of the UCS management system. Users authenticate through a regular form-based login, basic HTTP authentication or SAML.

In UMC, the UMC server implements SAML in the SAML service provider role. The UMC server considers SAML authenticated users as authenticated.

Fig. 5.14 shows how the UMC server handles user authentication.

Successful authentication

UMC server creates a session and returns a session cookie.

Unsuccessful authentication

UMC server denies the connection and answers with a denied request towards the user. The reasons can be manifold, for example:

  • Wrong username and password combination

  • Deactivated user account

  • Expired password

  • Locked account because of too many failed login attempts

../_images/UMC-authentication.svg

Fig. 5.14 Authentication chain in UMC#

The UMC server uses the PAM stack on UCS to validate and authenticate users for usual login and for SAML authentication. UMC server evaluates ACLs to grant or deny the usage of UMC modules. To find the user object for the authenticating user, UMC server runs an LDAP search for the username. It also allows to authenticate users with their email address. Furthermore, PAM recognizes deactivated user accounts, expired passwords, and allows to change an expired password during sign-in.

See also

Administrators, refer to Univention Corporate Server - Manual for users and administrators [1]:

User management module - Account tab

for information about deactivated and expired user accounts

Automatic lockout of users after failed login attempts

for information about failed login attempts and how UCS handles them in Samba, PAM and OpenLDAP

5.4.3. UMC backend#

The UMC backend consists of the following items as shown in Fig. 5.12:

  • Reverse proxy

  • UMC server

  • several UMC modules

In Fig. 5.15 you also see the Reverse proxy. In fact, the web server offering the Reverse proxy consists of more parts.

../_images/UMC-backend.svg

Fig. 5.15 Parts of the UMC backend#

Static HTTP server

First is the web server realized by Apache HTTP server. The web server provides the Static HTTP server that delivers the static files for the UMC web frontend. And the Static HTTP server responds with important HTTP headers for caching rules of the static files and security related headers like for example content security policy.

Reverse proxy

Second is the reverse proxy capability from the Apache HTTP server with the Apache module mod_proxy. The Reverse proxy also responds with important HTTP headers similar to the Static HTTP server.

The Reverse proxy redirects the following URI paths to the UMC web server:

  • /univention/set/.* as regular expression

  • /univention/auth

  • /univention/logout

  • /univention/saml/.* as regular expression

  • /univention/oidc/.* as regular expression

  • /univention/command/.* as regular expression

  • /univention/upload/.* as regular expression

  • /univention/get/.* as regular expression

UMC server

Further down the chain is the UMC server realized by Tornado, that only allows connections from the Reverse proxy. For example, it provides session management for signed in users.

The UMC server accepts requests with HTTP. For example, the UMC client uses it as connection endpoint. When a HTTP request reaches the UMC server, the UMC server maps the request to a dedicated UMC module depending on the URL and answers the request accordingly. The UMC server opens an IPC socket to the UMC module and they talk HTTP. It handles some requests directly, for example get/ and set/, and takes care of authentication and the language setting for the web content.

UMC module processes

UMC modules extend UCS with capability. For the description, refer to UMC modules.

5.4.4. UMC web frontend#

The UMC web frontend is responsible for the presentation layer of UMC and runs in the user’s web browser. It uses the modular JavaScript framework Dojo Toolkit to create dynamic widgets. And it uses the Bootstrap CSS framework for responsive designed web pages.

Fig. 5.16 provides a detailed view on the model of the UMC web frontend.

../_images/UMC-web-frontend.svg

Fig. 5.16 Model for UMC web frontend#

The UMC web frontend consists of static files for JavaScript, HTML and CSS. The UMC backend sends the static files to the user’s web browser, where the web browser presents UMC as a web application. The following packages from UCS source: management/univention-web/ contain the artifacts for the web front user interface:

univention-web-js

Contains the ready-to-use JavaScript files built with Dojo Toolkit.

univention-web-styles

Contains the ready-to-use CSS files for the web design including the graphical theme built with Bootstrap.

univention-management-console-frontend

Contains the HTML files for the UMC web frontend. More packages like univention-server-overview, univention-management-console-login, univention-system-setup, univention-portal and others also contain HTML files for the UCS management system.

5.4.5. UMC modules#

This section covers UMC modules. For the context of UMC modules, refer to UMC backend.

UMC modules extend UCS with capability. Each UMC module defines its command behavior with a Python implementation and its web frontend presentation with JavaScript as shown in Fig. 5.17.

../_images/UMC-module-architecture.svg

Fig. 5.17 Architecture of a UMC module#

Depending on the system role, UCS already installs UMC modules per default during installation. Such modules are for example the App Center, or Package Management. Furthermore, apps from the App Center can also extend UMC with additional modules, for example the OX License Manager or OpenVPN4UCS.

Every UMC module runs its own module process per user session on UCS with the user permission according to the requesting user. The encapsulation with separate processes ensures that UMC modules don’t interfere with each other. One disadvantage is the additional memory consumption of every UMC module process.

UMC module processes don’t run continually. After an idle time of ten minutes and if no open requests exist and no additional requests came in, module processes stop. The UMC server checks for running UMC module processes for every request. If the requested process doesn’t run, the UMC server starts the UMC module process.

Tip

Use umc/module/timeout to configure the idle time for the UMC module processes. The default value is 10 minutes.

See also

Development and packaging of UMC modules

for information about development and packaging for UMC modules in Univention Developer Reference [3]