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:

• Provide user account and user group information

• Notify about changes to directory objects

• Write data to the identity store

• Store configuration data

Fig. 3.21 Overview of the Identity Store and Directory Service

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.

Important

To maintain event consistency with the LDAP transaction log, the UDM Listener ties to the first LDAP Primary, The respective pod’s name is ldap-server-primary-0. If the first LDAP Primary is down, the UDM Listener doesn’t notify the Provisioning Service of changes to user and group objects until the first LDAP Primary comes back.

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.