⚠️ This document is work in progress. Feedback is welcome. ⚠️

2.4. Interfaces and protocols#

Nubus components offer services to clients and other components through network interfaces. Protocols define how services and other components use these interfaces. This section describes the interfaces each component offers, called inbound, and the interfaces it connects to, called outbound.

From an external perspective, Nubus offers the following protocols to the outside of the Nubus cluster:

Tip

This section uses the active structure elements Application Component and Application Interface from the application layer and the relationships Composition, Aggregation, and Serving of the ArchiMate notation.

For more information on these ArchiMate concepts, refer to the following sections in Univention Corporate Server Architecture [2]:

2.4.1. Authorization Service#

For a description of the Guardian, refer to Authentication and Authorization.

The Guardian consists of four separate components. Each offers and consumes services. The following sections show the services and protocols. Fig. 2.14 shows the interfaces and protocols of the Authorization Service.

ArchiMate view for the interfaces and protocols of the Authorization Service

Fig. 2.14 ArchiMate view for the interfaces and protocols of the Authorization Service#

2.4.1.1. Guardian Authorization REST API#

Inbound

HTTP on port 8000 provides REST API for other services to request authorization, using previously defined rules. The Guardian Authorization REST API needs a service account in the Identity Provider for authentication.

Outbound

2.4.1.2. Open Policy Agent#

Inbound

HTTP on port 8181 provides REST API to manage different aspects of the Open Policy Agent service. No authentication required. Not exposed through ingress. Only Guardian Authorization REST API uses this port.

Outbound

HTTP to the Guardian Management REST API to regularly fetch the current policy data.

2.4.1.3. Guardian Management REST API#

Inbound

HTTP on port 8000 provides REST API for CRUD operations on authorization objects, such as rules, namespaces, permissions, and roles, etc., and a policy bundle service for the Open Policy Agent.

Inbound requests require an OAuth 2.0 token for a user account with appropriate roles to access the authorization objects.

Outbound
  • HTTP to the Guardian Authorization REST API to authorize CRUD operations on authorization objects.

  • TCP connection to an externally managed SQL database or database cluster to persist authorization objects.

  • HTTP to Keycloak in Identity Provider to retrieve certificates.

2.4.1.4. Guardian Management UI#

Inbound

HTTP on port 80 provides a web application for the end user administrators to manage authorization objects, such as apps, rules, etc. To use the Guardian Management UI, you must have a user account with the appropriate roles to access the authorization objects.

Outbound

HTTP to the Guardian Management REST API for CRUD operations on authorization objects, using the previously received token.

2.4.2. Directory Manager#

For a description of the Directory Manager, refer to Directory Manager.

Inbound

HTTP on port 9979 provides a REST API offering CRUD operations on IAM objects, such as user account objects, user group objects, and asset objects, stored in the Identity Store and Directory Service.

The inbound access requires authentication using an LDAP object’s distinguished name (DN) as username and the object’s password. The UDM REST server first authorizes coarsely by checking user and group membership. The OpenLDAP server does a fine-grained control for each request and applies LDAP ACLs.

The HTTP REST API is the only interface to write IAM objects directly. For the interactive management of user account objects, user group objects, and asset objects, see the Management UI.

Outbound

LDAP connections to the Identity Store and Directory Service for authentication of UDM HTTP REST API access and CRUD operations on LDAP objects.

Fig. 2.16 shows the mentioned interfaces in an ArchiMate view.

ArchiMate view for the interfaces of the Directory Manager

Fig. 2.15 ArchiMate view for the interfaces and protocols of the Directory Manager#

2.4.3. End User Self Service#

For a description of the End User Self Service, refer to End User Self Service.

The Self Service consists of the following components:

UMC Gateway

See UMC Gateway in section Management UI.

UMC Server

See UMC Server in section Management UI.

Email Trigger Service

includes the Self Service Listener.

Inbound

None.

Outbound
  • TCP connection to the Univention LDAP Notifier to listen for notifications about changes in the Identity Store and Directory Service.

  • LDAP connection to the Identity Store and Directory Service for one-way synchronization of LDAP data.

  • HTTP to UMC Server in Management UI to request sending of user invitation email.

2.4.4. Identity Provider#

For a description of the Identity Provider, refer to Identity Provider.

The Identity Provider consists of the following components:

Keycloak
Inbound
  • HTTP on port 8181 for Keycloak authentication endpoints. Not exposed through ingress.

  • OpenID Connect interface to OpenID Connect Provider in Keycloak for authentication.

  • SAML interface to SAML Identity Provider in Keycloak for authentication.

OpenID Connect interface to OpenID Connect Provider in Keycloak for authentication.

SAML interface to SAML Identity Provider in Keycloak for authentication.

Outbound:
  • LDAP connection to the OpenLDAP server in the Identity Store and Directory Service used to authenticate access, and for one-way synchronization of user account and user group data.

  • TCP connection to an externally SQL managed database or database cluster for persistence for authorization objects and for handler-proxy communication.

In Nubus, Keycloak is also responsible for providing the protocols OpenID Connect and SAML.

See also

SSO protocols in Keycloak Server Administration Guide [4]

for more information about how to use those protocols in Keycloak.

Proxy
Inbound

HTTP on port 8181 for transparent proxy to Keycloak authentication endpoints. The Identity Provider only exposes this port through ingress.

Outgoing
  • HTTP to Keycloak for forwarded request.

  • TCP connection to an externally SQL managed database or database cluster for persistence for handler-proxy communication.

Handler
Inbound

None.

Outbound
  • SMTP to send an email to the user when there is a login from a new device.

  • TCP connection to an externally managed SQL database or database cluster for persistence for handler-proxy communication.

Fig. 2.16 shows the mentioned interfaces in an ArchiMate view.

ArchiMate view for the interfaces and protocols of the Identity Provider

Fig. 2.16 ArchiMate view for the interfaces and protocols of the Identity Provider#

2.4.5. Identity Store and Directory Service#

For a description of the Identity Store and Directory Service, refer to Identity Store and Directory Service.

The Identity Store and Directory Service consists of the following components:

LDAP Server
Inbound
  • LDAP on port 389 for the LDAP protocol server, port for TCP and UDP connections.

  • LDAP on port 636 for the LDAP protocol server, port for TCP and UDP connections over TLS.

Outbound

HTTP connection to Keycloak in Identity Provider to retrieve SAML metadata.

The LDAP Server provides access to the directory service through LDAP to the Nubus cluster.

Fig. 2.17 shows the before mentioned inbound ports. In some sections of this manual, the connection to the LDAP Server is just referred to as LDAP for the protocol without specifying the port.

Relationships between the LDAP Server and its inbound interfaces

Fig. 2.17 Relationships between the LDAP Server and its inbound interfaces#

Univention LDAP Notifier

The Univention LDAP Notifier is temporary, until the Provisioning consumer in Provisioning Service replaces it.

Inbound

Notifier on port 6669 that informs clients, such as the Self Service Listener in the Email Trigger Service of the End User Self Service, about changes in the Identity Store and Directory Service.

Outbound

None

Fig. 2.18 shows the mentioned interfaces in an ArchiMate view.

ArchiMate view for the interfaces and protocols of the Identity Store and Directory Service

Fig. 2.18 ArchiMate view for the interfaces and protocols of the Identity Store and Directory Service#

2.4.6. Intercom Service#

For a description of the Intercom Service, refer to Intercom Service.

Inbound

HTTP on port 8008 for general and app-specific endpoints for browsers.

Outbound
  • HTTP to frontends and backends of different web services, such as Nextcloud and Matrix for token exchange.

  • HTTP to Keycloak in the Identity Provider for token exchange.

  • Redis connection to an externally managed Redis database or Redis database cluster.

Fig. 2.19 shows the mentioned interfaces in an ArchiMate view.

ArchiMate view for the interfaces and protocols of the Intercome Service

Fig. 2.19 ArchiMate view for the interfaces and protocols of the Intercom Service#

2.4.7. Management UI#

For a description of the Management UI, refer to Management UI.

The Management UI consists of following components:

UMC Gateway
Inbound:

HTTP on port 80 to serve static files to the end user’s browser.

Outbound:

None

UMC Server
Inbound:

HTTP on port 8090 to multiplex connections to various RPC endpoints, the UMC modules.

Outbound:
  • LDAP connections to the OpenLDAP server in Identity Store and Directory Service to read and update user data.

  • HTTP connections to Keycloak in Identity Provider.

  • SMTP connections to send user invitation email.

  • TCP connection to an externally managed SQL database or database cluster for persistence for password reset requests.

  • Memcached connection to an externally managed Memcached database or Memcached database cluster for session storage.

Fig. 2.20 shows the mentioned interfaces in an ArchiMate view.

ArchiMate view for the interfaces and protocols of the Management UI

Fig. 2.20 ArchiMate view for the interfaces and protocols of the Management UI#

2.4.8. Portal Service#

For a description of the Portal Service, refer to Portal Service.

The Portal Service consists of the following components:

Portal Frontend
Inbound

HTTP on port 80 to serve static files to the end user’s browser.

Outbound

None

Note

Fig. 2.21 shows the additional ArchiMate application component Portal Frontend in User Browser. This application component isn’t part of Nubus, but runs software provided by the Nubus Portal Service.

The authors found it useful to introduce this application component to emphasize that the Portal Frontend application component doesn’t have any outbound connections, but the Portal Frontend software running in the user’s browser does.

Portal Frontend in User Browser

The Portal Frontend is a single-page application (SPA) consisting of HTML, JavaScript, CSS and media files. The user’s browser loads those artifacts and runs them.

Inbound

None

Outbound
  • HTTP connection to Portal Frontend to load the SPA.

  • HTTP connection to a S3-compatible storage to load generated Portal configuration.

  • HTTP connection to Portal Server running the backend.

Portal Server
Inbound

HTTP on port 80 running the backend for the Portal frontend code running in the end user’s browser.

Outbound
  • HTTP connection to an S3-compatible storage to load the generated Portal configuration.

  • HTTP connection to Management UI to retrieve session information.

Portal Listener
Inbound

None.

Outbound
  • TCP connection to the Univention LDAP Notifier in Identity Store and Directory Service to listen for notification about changes to portal and group objects in the LDAP database.

  • LDAP connection to the OpenLDAP server in Identity Store and Directory Service for one-way synchronization of LDAP data.

  • HTTP connection to an S3-compatible storage to store the generated Portal configuration.

  • HTTP connection to the UDM HTTP REST API in Directory Manager.

Notifications API
Inbound

HTTP on port 80 to provide the REST API for notifications in the Portal.

Outbound

TCP connection to an externally managed SQL database or database cluster for persistence for notification objects.

Fig. 2.21 shows the mentioned interfaces in an ArchiMate view.

ArchiMate view for the interfaces and protocols of the Portal Service

Fig. 2.21 ArchiMate view for the interfaces and protocols of the Portal Service#

Note

From the perspective of Portal Service functional component it uses the HTTP to S3-compatible Storage interface as outbound connection. The S3-compatible storage isn’t part of Nubus, see S3-compatible object storage in Univention Nubus for Kubernetes - Operation Manual [1]. From the storage’s perspective, all the connections are inbound.

2.4.9. Provisioning Service#

For a description of the Provisioning Service, refer to Provisioning Service.

The Provisioning Service consists of the following components:

Events and Consumer API
Inbound

HTTP on port 80 for the public REST API for LDAP change event consumers and internal REST API for the Dispatcher.

Outbound

TCP connection to NATS database.

NATS
Inbound
  • TCP port 4222 for NATS client connections.

  • TCP port 6222 to route connections for NATS clustering.

  • HTTP port 8222 for monitoring and reporting.

The inbound interfaces to NATS are only available from within the functional component Provisioning Service.

Outbound

None.

Dispatcher
Inbound

None.

Outbound
  • HTTP connection to Events and Consumer API.

  • TCP connection to NATS database.

Prefill
Inbound

None.

Outbound
  • HTTP connection to Events and Consumer API.

  • HTTP connection to UDM HTTP REST API in Directory Manager.

  • TCP connection to NATS database.

UDM Listener
Inbound

None.

Outbound

Fig. 2.22 shows the mentioned interfaces in an ArchiMate view. The only interface exposed to the outside world by the Provisioning Service functional component is the Events and Consumer API. The functional component uses all other shown interfaces internally within the functional component.

ArchiMate view for the interfaces and protocols of the Provisioning Service

Fig. 2.22 ArchiMate view for the interfaces and protocols of the Provisioning Service#