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
umc
directory, for example:UCS source: management/univention-management-console-module-join/umc/
UCS source: management/univention-management-console-module-adtakeover/umc/
UCS source: management/univention-management-console-module-diagnostic/umc/
UCS source: management/univention-management-console-module-ipchange/umc/
UCS source: management/univention-management-console-module-reboot/umc/
UCS source: management/univention-management-console-module-services/umc/
UCS source: management/univention-management-console-module-top/umc/
UCS source: management/univention-management-console-module-ucr/umc/
UCS source: management/univention-management-console-module-udm/umc/
UCS source: management/univention-management-console-module-welcome/umc/
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
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.
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
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.
- 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 aHTTP
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 talkHTTP
. It handles some requests directly, for exampleget/
andset/
, 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.
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.
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]