3.6. Intercom Service

This section provides an overview of the Intercom Service component in Nubus for Kubernetes, its components, features, and their relationships to each other. The service simplifies everyday work with web-based applications by organizing the intermediary communication between two or more applications in the background.

For example, a user writes an email using a web mail application and attaches files from a web-based file store. Typically, they need to sign in to the web-based file store, download the files to their client, and upload them as an attachment to the web mail application. The whole process involves multiple clicks for the user, takes time, and is cumbersome.

Imagine that the web mail application opens a file dialog box, where the user selects a file from the web-based file store. To make this work, you need the following ingredients:

• Functionality in the web mail application to display a file list and select a file.

• Functionality that handles authentication to the web-based file store in the background.

Fig. 3.27 shows the relationships between a generic Web Application, the Identity Provider with Keycloak, and the Intercom Service. The functionality, such as the file listing dialog, comes from an Extension in the web application. Depending on the use case, it may be necessary to provide both applications with additional functionality. The ArchiMate concept Extension in the web application symbolizes this in the figure. The Intercom Service handles the authentication in the background. It acts as a reverse authentication proxy, allowing communication between the applications.

Looking at the example again, before the user selects a file, the extension in the email application has already used the Intercom Service to authenticate the signed-in user to the web-based file store. When the user opens the file selector for the attachment, the extension requests a file listing from the web-based file store that has already authenticated with the signed-in user, receives a response, and can display the files available to the user.

The Intercom Service manages the authenticated sessions in the background as a silent procedure and stores them in Redis, an in-memory key-value database. It reverse-proxies the authenticated request to the other web application, such as the web-based file store in the previous example. In the process of forwarding the request, the authentication token from one application is exchanged for a token from the other application, allowing one application to embed the functionality of the other application on behalf of the user. The Intercom Service and the participating web applications use the OpenID Connect standard and Keycloak as the Identity Provider to authenticate a user in a session.

Fig. 3.27 Components of the Intercom Service for intermediary communication between applications

To enlarge the figure, follow the tips in How to use the document.

Note

The Intercom Service isn’t part of the Univention Nubus for Kubernetes default deployment.

See also

Intercom Service in the components overview section

for information about purpose and tasks.

Intercom Service Architecture in UCS Intercom Service App Manual [5]

for information about technical details, sequence diagrams, and endpoints.