Connecting new software to existing environments or migrating to a new IAM is usually a longer-term project. Nubus now offers new, lightweight options for integration with existing identity providers and directory services.

The initial situation: Existing identities & new projects

Organizations rarely start IT projects from scratch (“greenfield”) but usually have existing systems for managing and storing identities and for authentication. When new software is introduced, it is connected to these systems to avoid having to manage user accounts in yet another place and to enable users to log in via Single Sign-on or their familiar credentials.
Univention’s IAM Nubus is typically introduced in these environments for one of two reasons:

  1. As an identity broker for the introduction of new, modular software solutions: Nubus standardizes how user data is stored and how users authenticate against the applications and technical modules of new software. This relieves the often less flexible, existing identity providers. More information on this scenario can be found in our IAM whitepaper.
  2. To establish a leading identity store as an alternative to a proprietary, closed legacy system – for example, as a strategic replacement for a directory service based on Microsoft Active Directory.

In both cases, Nubus is connected to the existing identity management systems and authentication mechanisms. Even if the goal is a complete replacement of the legacy system, the migration must be carried out step by step. Therefore, it is usually necessary to ensure the synchronization of identity information between the legacy system and Nubus over a longer period.

Grafik Nubus IAM EN

The technical basis: Single Sign-on and “Ad Hoc Provisioning”

For users to easily access Nubus itself and the applications connected to Nubus, Single Sign-on with the legacy system is ideal. At the same time, this is a simple configuration task, since only Nubus has to be configured as a so-called “service provider” with the legacy system. No special permissions are required in the legacy system – it is sufficient to configure Nubus and the identity provider of the legacy system (e.g. Active Directory Federation Services) based on the OpenID Connect or SAML protocols.

New in Nubus is the option for “Ad Hoc Provisioning”, where user accounts are created or updated “ad hoc” directly upon successful Single Sign-on in Nubus. The information provided by the legacy system is used to populate a complete user account in Nubus. This allows users to immediately work with all applications connected to Nubus. Manual creation by an administrator or setting up a connector between the application and the IAM is not necessary.

The user accounts created this way can be enriched with additional information within Nubus. One use case could be assigning email addresses to users, enabling them to use a mail stack connected to Nubus.

Grafik IAM Nubus Ad Hoc Provisioning EN

Single Sign-on with Ad Hoc Provisioning is ideal for fast integration in environments with small to medium user numbers or in pilot and preliminary projects. This approach stands out due to quick configuration and low requirements for the existing environment. However, this process also has clear limitations that need to be considered. The most important are:

  • Only users who have logged in via the configured Single Sign-on in the past are known to Nubus. This becomes problematic especially when collaborative applications are used via Nubus and team members are missing because they have never logged in.
  • Data transfer based on the Single Sign-on protocols is limited – both in terms of timing (only at login) and the amount of user information. Updates to user information in Nubus only occur upon user login, so user accounts in Nubus may be outdated and not automatically locked or deleted. Users deleted in the leading system no longer log in, meaning the “user deleted” event is not transmitted to Nubus.
  • Only information that can be efficiently retrieved during SSO is transferred. The most important attributes like user ID and display name are always included, but additional data such as email aliases or account expiration dates are often unavailable or not standardized in the protocols. Currently, the Ad Hoc Provisioning implementation also omits the inefficient transfer of group membership information at this point.

A detailed description of how to set up Ad Hoc Provisioning can be found in the manual for the Keycloak App.

Full user lifecycle with the Nubus Directory Importer

In existing IT environments, directory services such as Active Directory are often used to store identities, which can be queried via LDAP. The “Nubus Directory Importer” can be used here to securely and efficiently transfer user and group information from the directory service to Nubus.

The Nubus Directory Importer communicates between the LDAP interface of the legacy system and the UDM REST API of Nubus. It transfers user and group information and automatically detects whether records need to be created, updated, or deleted in Nubus. This enables a complete user lifecycle.

Grafik IAM Nubus Directory Importer EN

The selection of information to be synchronized can be multi-level: The legacy system’s directory service can restrict which parts of the user and group data the Nubus Directory Importer is allowed to read via its service account. The “owner” of the data – the directory service – thus retains full control. The Nubus Directory Importer then determines, via a configurable mapping, which information is transferred to the UDM REST API of Nubus.

Thanks to its deployment as a Docker container, the operator is free to choose where in the network structure the data is processed by the Nubus Directory Importer. This is particularly beneficial when Nubus runs in a different network segment or is only accessible via the internet: the Nubus Directory Importer is operated where sensitive data can be handled – i.e. “close” to the legacy system. The Nubus REST API is then securely addressed via HTTPS, regardless of where Nubus is running.

The combination of Single Sign-on and Nubus Directory Importer results in convenient and secure integration for both users and operators. Users have easy access to Nubus and the connected applications and find their familiar structures such as groups and other users. Operators can be confident that the information in Nubus is up to date and only relevant data is transferred.

Grafik Nubus IAM User Lifecycle EN

The setup of the Nubus Directory Importer is described in the Nubus Operations Manual for Kubernetes. It can be used both on Kubernetes and on any Docker Compose-capable operating system and is compatible with Nubus in a UCS environment as well as with Nubus for Kubernetes.

Step-by-step deployment: start easily and keep all options open

The implementations of Ad Hoc Provisioning and the Nubus Directory Importer are coordinated and can build on each other. For a quick project start, it is advisable to begin with Single Sign-on and activated Ad Hoc Provisioning to quickly provide users access to the required IT services. This enables fast and user-friendly integration, even for preliminary projects and evaluation phases.

If simple user account synchronization is no longer sufficient, the Nubus Directory Importer can be activated in a later project phase, in addition to Single Sign-on. This ensures complete and continuous maintenance of user and group information. The user experience improves significantly. With full synchronization, Nubus’s directory service component also becomes a potential alternative to the legacy system.

And what about the Active Directory Connection?

In addition to the Nubus Directory Importer, the Active Directory Connection has long been available to our users. This can also be used to synchronize user accounts and groups between Microsoft Active Directory and Nubus. The Active Directory Connection offers significantly more functionality than the Directory Importer: it can also write information back to Active Directory and thus supports bidirectional synchronization, and it transfers password hashes between Active Directory and Nubus. However, the Active Directory Connection is currently only available for UCS. Its functionality is designed for scenarios where Nubus is the leading system, and it therefore requires significantly more access rights to Active Directory. In projects where Nubus is intended to read from an existing directory service, the Active Directory Connection is too invasive – and if the source system is not Active Directory, it cannot be used at all. In such cases, the Directory Importer plays to its strengths.

Conclusion: Identity integration with new flexibility

With Ad Hoc Provisioning and the Nubus Directory Importer, Nubus now offers two complementary implementations that significantly expand its integration and usage possibilities. Both are available for Nubus in UCS and Nubus for Kubernetes.

Whether for integrating modular software offerings like openDesk, using Nubus as part of a SaaS solution, or building alternatives to existing directory services – in all cases, these functions provide significant simplification for managing user identities and access rights across applications.

Cooperation with Zentrum für Digitale Souveränität

The implementations for Ad Hoc Provisioning and the Nubus Directory Importer were created in cooperation with and supported by the Zentrum für Digitale Souveränität (ZenDiS) for integration into openDesk. The options described here therefore also apply to the connection of openDesk to existing systems.

Use UCS Core Edition for Free!
Download now

Leave a Reply

Your email address will not be published. Required fields are marked *