3.2. Directory Manager#
The Directory Manager is an abstraction layer for Directory objects in the Identity Store and Directory Service. It applies consistency checks and other business logic during the conversion of directory objects to UDM objects, an internal representation of data from the directory service. The main job of the Directory Manager is to provide the UDM HTTP REST API for create, read, update, and delete operations, so called CRUD operations, to the Identity Store. It’s the only component in Nubus with write permissions to the directory service. The UDM HTTP REST API is available to Nubus components and third-party applications on the same cluster network.
The Nubus Portal Service, Provisioning Service, Authorization Service and Stack Data are the consumers of the UDM HTTP REST API. Stack Data uses the CRUD operations on UDM objects to load initial data into the directory service. The Portal Service, Provisioning Service, and Authorization Service functional components also use the UDM HTTP REST API and its CRUD operations to read and write UDM objects.
Fig. 3.6 Functional components relying on the Directory Manager#
Fig. 3.7 shows the dependencies for the Directory Manager. It depends only on the Identity Store and Directory Service.
Fig. 3.7 Dependencies of the Directory Manager#
See also
- Directory Manager in interfaces and protocols section
for information about incoming and outgoing interfaces.
- Directory Manager in deployment view section
for information about Docker images, Kubernetes pods, and Helm Charts used for deployment.
- Directory Manager in overviews section
for information about purpose and tasks.
- Directory objects in data objects section
for information about Directory objects.
- UDM objects in data objects section
for information about UDM objects.
3.2.1. Internal functions#
The Directory Manager uses the following functions from the UDM Library to provide the CRUD operations for UDM objects service, as shown in Fig. 3.8:
Business logic for directory objects
Transform UDM objects to and from directory objects
The UDM Library is of central importance here. Its purpose is to provide the following functionality:
- Business logic for directory objects
It’s responsible for data integrity when writing to the Identity Store and Directory Service. It applies consistency checks and other business logic, and it guarantees stable values encoding and attribute names.
For example, it creates multiple hashes for a user password and stores them in the directory object. The password hash for Kerberos uses a different hash function than for Keycloak.
- Transform UDM objects to and from directory objects
It converts UDM objects to Directory objects, and the other way around. Many components in Nubus use UDM objects, because they rely on the business logic that the Directory Manager applies when transforming objects.
Fig. 3.8 Internal components of the Directory Manager#
3.2.2. Authentication and authorization for CRUD operations#
When a user signs in to Nubus, they must authenticate themselves. The same principle applies to the Directory Manger, as well. Fig. 3.9 shows that the Directory Manager uses access control list based authentication through LDAP to determine what the actor using the directory manager can do in the directory service.
Fig. 3.9 The Directory Manager uses authentication and authorization through ACLs#
See also
- Wikipedia: Access-control list
for more information about ACLs and content of ACLs.
3.2.3. Populate data on initial startup of Nubus#
When Nubus for Kubernetes starts up for the first time, the Identity Store and Directory Service populates initial data to the directory service using the UDM HTTP REST API. Fig. 3.10 shows the data flow.
Nubus initial startup is the event that triggers Load initial data for directory service. The initial data is a representation of UDM objects. The Stack Data component is the owner of the initial data. It populates the following initial content through the UDM HTTP REST API:
Default users
Default policies
Default portal tiles
The UDM HTTP REST API uses LDAP for the write operations.
Fig. 3.10 Populate initial content into the Identity Store and Directory Service upon first Nubus startup#