Sovereign IT with Open Source: How to Build Your Own Modular Application Stack

Digital independence begins with IT architecture: organizations that want to operate IT services sovereignly need open standards, centralized identity management, and full control over users, roles, and access. This article describes how IAM becomes the solid foundation of a modular application stack – flexible, secure, future-proof, and easier than you might think.

Digital sovereignty is more than an internet hype or marketing slogan. It determines whether organizations can shape their processes themselves – or remain dependent on vendors, licensing models, and proprietary interfaces. The good news: by relying on open standards and open source, a wide variety of IT services can be seamlessly integrated – from file servers to specialized applications – allowing the step-by-step construction of a software stack optimized for one’s own needs, benefiting from its modularity and gaining independence from hyperscaler services.

For applications and services to work smoothly together, a connecting element is required: an Identity & Access Management (IAM) system that handles the integration and management of users, roles, and permissions – securely linking all applications and enabling cross-application data flows. Such an IAM manages user identities, regulates access rights, and allows the automation of entire process chains.
In short: without IAM, there is no application stack – at least not one that remains controllable in the long term.

Below, I will introduce central building blocks for a technically sound implementation of an open IAM and show which standards have proven effective and which architectural decisions make the difference – from single sign-on with OpenID Connect or SAML, single logout via frontend or backchannel logout, user lifecycle management with SCIM, a single source of truth for roles and contextual control of permission assignment, automation and deployment with Kubernetes & Helm, to provisioning.

Organizations that want to operate an application stack themselves need more than containers, computing resources, and a colorful mix of (open-source) components. The challenge lies in a well-thought-out architecture: how do all services interact cleanly – and how is the overview of access, roles, and data flows maintained?

This is exactly where Identity & Access Management (IAM) comes into play. As versatile as modern applications are, without centralized identity and access management, shadow identities, fragmented roles, and security gaps arise. Without overarching IAM, organizations sooner or later face the same problems as with traditional silo solutions: login credentials circulate via email, former employees retain unintended access to sensitive data, and no one really knows who has which rights. An open IAM solves these problems based on established protocols and interfaces.

A solid foundation alone does not yet make a secure house. The right building blocks are also needed – starting with authentication.

A modern application stack often includes services such as file storage, webmail, video conferencing, office and project management software, or industry-specific applications. To prevent login from becoming increasingly complex and time-consuming for users across these applications, a central authentication mechanism is needed: single sign-on (SSO).

With SSO, users log in once and gain access to all connected services. Authentication is carried out using protocols such as OpenID Connect (OIDC) or SAML. Both are widely adopted open standards supported by almost all modern web applications.

SSO is convenient – but it only solves half the problem. While logging in usually works smoothly, logging out often falls short. Single logout (SLO) means that logging out once also closes all sessions in the connected services. In practice, this step is often overlooked – with consequences for security and data protection. Logging out of the email client does not automatically terminate sessions in the video conference service, file storage, or project platform – a potential avenue for misuse.

Depending on the protocol used, different single logout methods exist – for example, frontend logout, where the browser actively terminates all sessions, or backchannel logout, where the IAM communicates directly with connected services. Which method is possible depends on the capabilities of the respective application and the care taken in technical integration.

Reality shows: while SSO is often quickly hailed as a success, SLO is the real challenge. A missing logout mechanism may seem harmless, but it can become a security risk – especially with sensitive data or public workstations.

Single sign-on enables convenient access to IT services, but what happens before and after? Proper user account management requires monitoring the entire lifecycle of identities: from creating new users or groups, through changes, to deletion. This is what user lifecycle management is about.

Many systems rely solely on the login event: an account is automatically created when someone logs in for the first time. This may suffice for simple scenarios – but for controlled, traceable IT management, this model is insufficient. What happens if someone never logs in? Or if a person leaves the organization?

Without centralized event control, shadow identities – accounts existing in the system but no longer linked to a person – emerge quickly. Rights and group memberships are difficult to synchronize, too. Losing oversight is not just an organizational issue but also a data protection and security problem.

For technical implementation, several approaches exist:

• Via APIs – whether open or proprietary – data can often be written directly to target systems. This offers flexibility but usually comes with high integration effort and low reusability.
• Directory services (e.g., LDAP-based) can serve as a shared source for user and group data but generally only work with systems that actively access them.
• System for Cross-domain Identity Management (SCIM) is an open standard for provisioning identity data. It allows events like account creation, name changes, or deletion to be transmitted automatically and standardized between systems – including groups and permissions.

Comprehensive user lifecycle management with SCIM or a comparable mechanism is not only more convenient but also safer. It prevents data remnants, reduces errors, and allows identities to be managed consistently across system boundaries – regardless of the size or heterogeneity of the stack.

Access alone is not enough – equally important is the question: what is a user allowed to do within an application? An open IAM must not only manage identities but also assign and control permissions in a differentiated manner. Groups, roles, and permissions must be represented so they can be automatically transferred to different applications. Many IAM systems rely on role models assigning certain rights to user groups – e.g., “teacher,” “employee,” “project manager,” or “admin.”

Technically, there are two common approaches:

• OIDC allows roles and permissions to be included in claims, which contain information such as groups, role names, or attributes – e.g., role=project-admin. This works well but requires IAM and applications to agree on what each term means. It is not standardized.
• SCIM goes a step further: it explicitly defines how entitlements and roles can be provisioned. Groups and rights can be transferred and kept consistent across systems – provided the target application fully supports SCIM. Like OIDC, IAM and applications must agree on the meaning of entitlements.

In practice, limits are quickly reached. Many applications interpret claims differently or ignore entitlements entirely. To be safe, a clear architectural decision is required: there must be a leading instance where users, roles, and permissions are managed – a single source of truth. An IAM ideally fulfills this role: storing rights centrally, synchronizing them with other systems, and remaining independent of specific applications.

In addition to static role-based permissions, contextual control is gaining importance: who can access what, when, where, and from which device – modern IAM systems can represent these conditions in a granular manner. This results in a permissions model that is not only differentiated but flexible enough for hybrid scenarios.

Organizations that want to reliably operate open components like IAM, directory services, office applications, or file storage need a platform that enables repeatable deployments, updates, and integrations – even in running operations.

Kubernetes has become the standard in many organizations for operating containerized applications scalably and resiliently. Combined with the Helm package manager, complex setups like an IAM with associated services can be described declaratively, installed automatically, and reproduced as needed – e.g., in test, integration, and production environments.

In self-built application stacks, this is essential: without automated deployment, releases quickly become confusing, configurations inconsistent, and extensions risky. Kubernetes and Helm provide structure and make it easier to operate IAM modularly, update it regularly, and integrate it traceably. Prerequisite for this repeatability is a consistent continuous delivery approach. Only when builds, tests, and deployments are standardized and automated can the quality of the overall system be reliably ensured – across many components.

Many organizations already have established infrastructures – e.g., a central Active Directory for user management. Achieving digital sovereignty does not require starting from scratch; existing systems can be cleverly integrated.

When introducing an open IAM, it is often sensible to include existing directories initially and import or synchronize identity data from them. In hybrid scenarios, the new IAM can become the leading system or run in parallel to the existing directory, gradually replacing it step by step.

Technically, several options exist: manual exports can be implemented quickly but are error-prone and unsustainable. Better are connections via LDAP, SCIM, or API, where changes in user data are retrieved automatically or event-driven. Crucial is that processes like onboarding, role assignment, and offboarding work seamlessly – regardless of where the data is maintained.

In practice, a gradual transition is often advisable: existing systems remain initially, while new components are integrated and tested according to standards. This allows a controlled change – without loss of functionality but with growing control.

A modular application stack consists of more than individual services – the interaction between them is decisive. Only when identities, roles, applications, and data flows are integrated via open standards does an architecture emerge that can be operated independently, adapted, and sustainably maintained. That this is practicable even in very large environments is demonstrated by the project openDesk, promoted by the Zentrum für Digitale Souveränität.

openDesk relies on a combination of proven open-source components: Open-Xchange for email and calendar, Nextcloud for files, Collabora for online document editing, Element for messaging, OpenProject for project management – and the IAM Nubus from Univention GmbH, which as a central link enables the technical interaction of the components and convenient access to all services via a modern portal. The modular setup works – for example at the Robert Koch-Institut and in the Bundestag administration.

Nubus demonstrates the important role an open IAM can play: it not only manages identities but also centrally controls access rights and provides this information via open interfaces. An example is the ambitious open-source project of the state of Schleswig-Holstein, which is currently building a new statewide directory service with Nubus. This will eventually replace the previous Active Directory environment and enable secure access to specialized applications, devices, and central IT systems – role-based, data protection compliant, and fully under local control.

Diagram 3: Modular infrastructures illustrated using the openDesk case study

To get started with a sovereign cloud infrastructure using Nubus as IAM, pre-configured integrations are helpful. For example, the Active Directory connection allows an open IAM to synchronize with an existing AD – including accounts, groups, and passwords. There are also ready-made integration packages for complete applications such as Nextcloud or Open-Xchange, which make connecting third-party software to Nubus particularly easy. Further packages are being developed and gradually released. Connector tools for Google Workspace, Apple School Manager, or Microsoft 365 also support single sign-on to these cloud services. These tools facilitate a smooth transition to open, controllable architectures – without having to replace everything immediately.

These projects show: digital sovereignty is not an abstract goal but can be concretely implemented with open source – step by step, traceably, and sustainably.

Digital sovereignty is not created by a product label but by an architecture that remains open, controllable, and adaptable. Organizations that want to operate IT services themselves or integrate them into existing structures need an IAM that grows with them – from authentication through roles and permissions to full automation.

Many organizations build their own IAM systems from LDAP, scripts, and database reconciliations in hopes of maximum flexibility. Such homemade solutions quickly hit limits: lack of logging, poor scalability, security risks. Using an established open-source IAM, by contrast, offers tested standards, community support, and extensibility – without technical debt.

A sovereign IT stack needs more than containers and services. Only with a central IAM can identities, roles, and access rights be reliably managed – across all applications. It is the connecting element that turns individual parts into a functional whole: interoperable, controllable, and sustainably maintainable.

This article has already been published in Informatik Aktuell and can be viewed here.