For Nubus for Kubernetes

6.3. For Nubus for Kubernetes#

The OX Connector provisions selected identity data from Nubus for Kubernetes into OX App Suite. It receives directory changes through the Provisioning API. It sends create, update, and delete requests to the OX App Suite SOAP API.

Before you continue reading, ensure you know Shared architecture.

6.3.1. Overview#

The OX Connector runs as an OX Connector Provisioning Consumer in the Kubernetes cluster. The consumer receives changes from the Provisioning Service for selected Univention Directory Manager (UDM) modules. It processes the changes and provisions the corresponding OX App Suite objects. Fig. 6.4 shows the following components, their boundaries, and dependencies:

  1. Identity Store and Directory Service

  2. Directory Manager

  3. Provisioning Service

  4. Provisioning API

  5. OX Connector Provisioning Consumer

  6. OX App Suite

Nubus for Kubernetes components that provision directory data to OX App Suite through the OX Connector.

Fig. 6.4 OX Connector components for Nubus for Kubernetes#

Subscription#

A subscription defines the Provisioning Service topics for which the OX Connector Provisioning Consumer receives messages.

PostgreSQL database: OX Connector#

The OX Connector Provisioning Consumer requires a PostgreSQL database for the task queue and object state. The database helps the connector keep track of objects when synchronization errors occur. The database isn’t part of the OX Connector deployment.

For descriptions of shared components, see Shared architecture.

6.3.2. Deployment#

You deploy the OX Connector as a Helm release in the Kubernetes cluster. The release creates a StatefulSet with the following containers:

  • A main OX Connector container

  • A container that waits for the Provisioning API

  • An initialization container that prepares the connector database

The consumer uses a configured PostgreSQL database for its task queue and object state. Fig. 6.5 shows the deployment of the OX Connector components.

OX Connector image and wait-for-dependency image running in the OX Connector pod with its database.

Fig. 6.5 Deployment view for OX Connector components#

6.3.3. OX Connector Provisioning Consumer behavior#

The OX Connector connects to the Provisioning API within the cluster. Nubus for Kubernetes doesn’t expose the Provisioning API outside the cluster.

The OX Connector Provisioning Consumer processes one provisioning message at a time. Fig. 6.6 shows the main processing flow.

Provisioning flow from the Nubus directory to OX App Suite through the OX Consumer and its database.

Fig. 6.6 OX Consumer provisioning flow#

The following list describes the provisioning flow:

  1. A change to a subscribed UDM object creates an event in the Provisioning Service.

  2. The Provisioning API sends the event to the OX Consumer subscription.

  3. The OX Consumer stores the event as a task in its database.

  4. The consumer processes the event and sends its data to the SOAP API in OX App Suite.

  5. After successful processing, the consumer stores the object state in its database.

When the message handler returns successfully, the Provisioning API acknowledges the message. If an exception escapes the message handler, the Provisioning API doesn’t acknowledge the message and redelivers it. The consumer process then stops. Kubernetes restarts the process with fresh network connections.

The consumer processes context changes before dependent object types. It then processes the following object types:

  • Context changes

  • Access profiles

  • Users

  • Groups

  • Functional accounts

  • Shared account permissions

  • Shared accounts

  • Resources

  • Context deletions

Detailed OX Connector Provisioning Consumer processing, click to open.

Fig. 6.7 shows the task queue, the database for OX Connector, and the SOAP provisioning step. The diagram also shows the relation between the Provisioning API, the OX Consumer, and OX App Suite.

Detailed OX Consumer flow including message reception, task storage, SOAP provisioning, and database state.

Fig. 6.7 Detailed OX Consumer provisioning flow#

Click the diagram to zoom in.

6.3.4. Provisioned attributes#

For information about provisioned attributes, see Shared architecture.

6.3.5. Database of stored object state#

The OX Connector Provisioning Consumer stores pending tasks and object state in the configured SQL database. An initialization container prepares the database when the OX Connector starts.

When the old and tasks tables are empty, the initialization container requests a prefill from the Provisioning Service. It skips the request if its configuration doesn’t enable resynchronization or if it can’t access the required credentials.

For information about stored object state and OX internal IDs, see Shared architecture.

On this page