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:
Web interface presentation layer at UCS source: management/univention-web/
Packages with UMC modules usually include a
umcdirectory, for example:
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.
The UMC frontend has the following items:
UMC web frontend
The UMC backend has the following items:
Static HTTP server
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.
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
use UMC through the UMC web frontend or through specific command-line tools.
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.
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
Locked account because of too many failed login attempts
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.
Administrators, refer to Univention Corporate Server - Manual for users and administrators :
- 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:
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.
- 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
The Reverse proxy redirects the following URI paths to the UMC web server:
/univention/set/.*as regular expression
/univention/saml/.*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
HTTPrequest 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
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#
Fig. 5.16 provides a detailed view on the model of the UMC web frontend.
Contains the ready-to-use CSS files for the web design including the graphical theme built with Bootstrap.
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.
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.
umc/module/timeout to configure the idle time for the UMC module
processes. The default value is 10 minutes.