3.5. Identity Store and Directory Service#
This section describes the Identity Store and Directory Service functional component of Nubus for Kubernetes, the functions, components, and their relationships to each other. For a simplified understanding you can think of the Identity Store and Directory Service providing an LDAP server as directory service, more specifically OpenLDAP.
The components in the following list and shown in Fig. 3.21 use data from the Identity Store and Directory Service:
Keycloak in the Identity Provider
UMC Server in the Management UI
UDM HTTP REST API in the Directory Manager
Portal Consumer in the Portal Service
UDM Listener in the Provisioning Service
They use the Lightweight Directory Access Protocol (LDAP) for read operations and for accessing Directory objects. An LDAP proxy manages the requests from the components and, depending on the type of request, it forwards the request to either LDAP Primary for write operations or LDAP Secondary for read operations. By separating roles and responsibilities, this architectural design enables high availability and scalability of the directory service. The Univention LDAP Notifier monitors changes to directory objects and makes them available to other components that implement a so-called listener. The notifier provides the old and the new directory object, so that the other component can react to the change accordingly.
Third Party Applications that aren’t part of the Nubus for Kubernetes deployment can also use the Identity Store and Directory Service.
The Identity Store and Directory Service stores various information types. During the initial startup of Nubus for Kubernetes, a data loader populates initial data to the Identity Store and Directory Service using the UDM HTTP REST API. For more information, see the Populate data on initial startup of Nubus in the Directory Manager section.
Important
Nubus only supports write operations to the Identity Store and Directory Service through the UDM HTTP REST API in the Directory Manager functional component, because the Directory Manager applies business logic and sanity checks to ensure data consistency.
The Identity Store and Directory Service has the following jobs:
Fig. 3.21 Overview of the Identity Store and Directory Service#
To enlarge the figure, follow the tips in How to use the document.
See also
- Identity Store and Directory Service in the interfaces and protocols section
for information about protocols and interfaces.
- Identity Store and Directory Service in the deployment view section
for information about Kubernetes pods, Docker images, and Helm Charts.
- Identity Store and Directory Service in the functional components overview section
for information about purpose and tasks.
- Directory objects in data objects section
for information about Directory objects.
- Wikipedia: LDAP Protocol
for information about the Lightweight Directory Access Protocol.
- Wikipedia: OpenLDAP
for information about of components, backends, overlays, and other modules of OpenLDAP.
3.5.1. Information types in identity store#
The Identity Store and Directory Service saves Directory objects in an LDAP Server. Nubus for Kubernetes uses OpenLDAP with the Lightning Memory-Mapped Database (LMDB) storage backend. The directory service applies LDAP for its read and write operations. The directory service stores the following directory objects, as Fig. 3.22 shows:
User account information
User group information
Permission information for the management console
Various configuration information, such as:
User templates
Extended attributes
License information
Fig. 3.22 ArchiMate view about directory objects representing the type of information in Directory objects in Identity Store#
See also
- Wikipedia: Lightning Memory-Mapped Database (LMDB)
for more information about technical description, performance, APIs and reliability.
3.5.2. Provide user account and user group information#
The main job of the Identity Store and Directory Service is to provide user account and user group information to Nubus for Kubernetes components and third-party applications for authentication and authorization tasks. They use LDAP to connect to the directory service. Identity information administrators manage user account information and user group information using the Management UI.
Fig. 3.23 shows which components in Nubus require user account and user group information. The following components within the functional components use it:
Keycloak in the Identity Provider
UMC Server in the Management UI
UDM HTTP REST API in the Directory Manager
Third-party applications can also retrieve user account and user group information through LDAP, as long as they use the same cluster network.
Fig. 3.23 Components using user account and user group information stored in the Identity Store and Directory Service.#
See also
- Management UI in the functional components overview section
for information about the Management UI.
3.5.3. Notify about changes to directory objects#
The Identity Store and Directory Service provides the LDAP Notifier to notify other components of changes to directory objects, so that those components can react. Fig. 3.24 shows the relationships. The LDAP Notifier notifies the UDM Listener in the Provisioning Service about changes to directory objects, because the job of the Provisioning Service is to deliver those changes as events to other components.
Fig. 3.24 LDAP Notifier informs about modifications on directory objects.#
See also
- Provisioning Service in the functional components overview section
for more information about the purpose and tasks of the Provisioning Service.
3.5.4. Write data to the identity store#
To write data to the Identity Store and Directory Service, users and applications must use the Directory Manager. The Directory Manager is the only functional component with write permission to the directory service. One exception is the UMC Server in the Management UI. It writes to the directory service directly using the same implementation and logic as the Directory Manager.
All other Nubus components, such as the Management UI in Fig. 3.25, and third-party applications in the cluster network have read-only permissions by default.
Important
Univention doesn’t support writing data directly to the directory service through LDAP.
For write operations, use the Directory Manager with its UDM HTTP REST API, because the Directory Manager applies business logic and sanity checks to ensure data consistency.
Fig. 3.25 Write identity information with the Directory Manager to the identity store.#
See also
- Directory Manager in the functional components overview section
for information about the HTTP REST API provided by the Directory Manager and more.
3.5.5. Store configuration data#
The Identity Store and Directory Service stores configuration data for other components, such as the Management UI and the Portal Service, as shown in Fig. 3.26.
The components use LDAP to retrieve their configuration information from the directory service. To write configuration data to the directory service, the components use the following approaches:
The Portal Service uses the UDM HTTP REST API.
The Management UI writes directly using the same implementation as the UDM HTTP REST API, the UDM Library.
Fig. 3.26 Configuration Information as a part of Directory objects in Identity Store.#