5.5. UCS portal service#
This section describes the technical architecture of the UCS portal service. For a general overview, see UCS portal.
Every UCS system role installs the UCS portal and its dependencies per default. The UCS portal generates structured data in the JSON format. The data persistence layer consists of cache files with structured data in the JSON format. The UCS portal needs information about the tiles on the portal and about user memberships in user groups. Portal frontend and backend use HTTP for communication.
You find the source code at UCS source: management/univention-portal/.
Fig. 5.18 shows the architecture of the UCS Portal and the description below.
Fig. 5.18 Architecture of the UCS Portal#
The User uses the UCS Portal through a web browser with HTTP/HTTPS. The Portal frontend and the backend together realize the UCS portal. The Portal backend validates the user login with the UMC server and uses structured data from the UCS Portal tile cache and the UCS group cache.
The UCS Portal uses the following technology:
- HTTP request handler
The UCS Portal backend uses Tornado to handle the HTTP requests from the frontend and to serve the data to the frontend. Tornado is a Python web framework and asynchronous networking library.
- Single-page application
Vue.js with TypeScript is the technology behind the web frontend of the portal. It serves the single-page application of the portal to the user. The decision came to Vue.js, because it’s flexible, painless, and not owned by a company. The implementation began with Vue.js 3, because it has full TypeScript support and many improvements compared to Vue.js 2.
5.5.1. Portal frontend#
The portal frontend is a single-page application and renders the UCS portal in the users’ web browser. Users see for example the portal header, background image, a menu and various tiles consisting of logo, title, and description.
The portal requests the structured data in portal.json about what to
render from the Portal backend.
5.5.2. Portal backend#
The portal backend generates the data about what portal the frontend renders for the user.
The portal backend delegates the user authentication to the UMC server. It maintains internal caches for the portal content and the user group memberships. It doesn’t request LDAP or Univention Directory Manager (UDM) directly.
Fig. 5.19 shows the architecture of the portal backend. A description about the elements and their responsibility follows.
Fig. 5.19 Architecture of the UCS Portal backend#
- UCS Portal tiles cache
Provides structured data about the tiles configured for every portal in the domain. Every tile has assignments to user groups.
- UCS group cache
Provides structured data to resolve a user and its group memberships including nested groups.
- UMC server
Validates user authentication for a given user.
- Univention Directory Listener
In the context of the UCS Portal, the Univention Directory Listener triggers the update of the UCS portal tile cache and the UCS group cache.
User identification#
Fig. 5.20 shows the basic model of the user identification. The description follows below.
Fig. 5.20 User identification in the UCS Portal#
The user is either an anonymous user or has user information from a login.
The portal frontend sends an HTTP request with user information to the portal backend.
The portal backend delegates the user validation to the UMC server.
The UMC server returns the login status.
Based on the login status the portal backend generates the structured data for the portal frontend.
Structured data for portal content#
The structured data in portal.json for the portal frontend has
information for example about folders in the menu, categories in the portal main
area, portal design, the entries for the menu and the portal tiles. For example,
the anonymous portal data from the UCS demo system.
The content depends on the user login status:
- Anonymous users
Anonymous users see portal content that’s publicly available.
- Signed in users
Signed in users see public content and content depending on their group memberships. One user may also see different tiles than another user.
The portal backend uses the caches in the following sections to generate the structured data.
UCS portal tile cache#
The portal tile cache has information about the content of every tile like name, description, logo, and category. Furthermore, it knows the group assignment for every tile.
When administrators create or modify a portal in the UMC module LDAP directory, the Univention Directory Listener reacts on this change and triggers the listener module responsible for the portal tile cache. The module then uses UDM and recreates the portal tile cache.
The portal tile cache uses structured data, as well. The listener module saves it in a JSON file in the file system of the UCS system.
UCS group cache#
The User identification returns information about the user without data about the users’ group memberships and nested groups. The group cache steps in and provides a mapping for users to their groups.
Running the user’s group resolution on the fly is an expensive operation especially for large environments.
To mitigate the expensive operation, the Univention Directory Listener triggers the respective listener module in the post-run when no more changes happen to user groups for 15 seconds. The group cache retrieves the necessary information from the key-value store of the UCS group membership cache.
5.5.3. Dependencies for UCS portal#
The UCS portal depends on the Univention Directory Listener, Univention Directory Manager (UDM), the UCS group membership cache, and the UCS Portal tile cache. Table 5.1 lists the depending services and their packages:
Service |
Package name |
|---|---|
UCS configuration manager |
univention-config |
Univention Directory Listener |
univention-directory-listener |
UCS command-line based administration tools |
univention-directory-manager-tools |
UCS group membership cache |
univention-group-membership-cache |
univention-management-console-server |