SSO und ERP-Anbindung: So docken Kundenportale an Bestandssysteme an

„Unser ERP kann das nicht.“ An diesem Satz aus der IT-Abteilung sterben mehr Kundenportal-Projekte als an jedem Budget-Veto. Er beruht allerdings auf einer falschen Annahme: dass das Altsystem die Integrationsarbeit leisten muss. Muss es nicht. Die Anbindung ist Aufgabe des Portals — genauer: einer Integrationsschicht, die zwischen Portal und Bestandssystemen sitzt. Was Ihr ERP dafür tatsächlich können muss, ist überraschend wenig.

Dieser Artikel beantwortet die zwei technischen Fragen, die jedes Kundenportal-Projekt vor der ersten Zeile Code klären sollte: Wie kommen Nutzer sicher hinein — also Identity, SSO und Rollen für Kundenorganisationen? Und wie kommen Daten sicher heraus — also die Anbindung an ERP und CRM? Beides sind gelöste Probleme, wenn man die richtigen Muster wählt. Und beides entscheidet darüber, ob das Portal Support-Anfragen wirklich ablöst oder nur verschiebt.

Ein Kundenportal ohne Bestandssystem-Anbindung ist eine Broschüre mit Login. Kunden melden sich an, sehen statische Inhalte — und rufen dann doch an, weil der Auftragsstatus fehlt. Genau daran scheitert Self-Service in der Praxis: Laut Gartner (2019) nutzen 70 Prozent der Kunden auf dem Weg zur Problemlösung irgendwann einen Self-Service-Kanal, aber nur 9 Prozent lösen ihr Anliegen vollständig ohne Live-Kontakt. Der Abstand zwischen diesen beiden Zahlen liegt selten am Frontend. Er liegt an den Daten dahinter: Auftragsstatus, Rechnungen und Liefertermine leben im ERP — und wenn das Portal sie nicht aktuell zeigt, verschiebt es den Anruf nur um zehn Minuten nach hinten.

Dass Integration die eigentliche Baustelle ist, belegt der MuleSoft Connectivity Benchmark 2025: Unternehmen betreiben im Schnitt 897 Applikationen, aber nur 29 Prozent davon sind miteinander integriert — und nur 2 Prozent der Organisationen haben mehr als die Hälfte ihrer Systeme verbunden. Ein Kundenportal, das als Applikation Nummer 898 einfach danebengestellt wird, macht dieses Problem größer. Richtig geschnitten wird es dagegen zur ersten Schicht, die Bestandsdaten überhaupt konsumierbar macht — erst für Kunden, später auch für andere Systeme.

Bevor Daten fließen, braucht das Portal eine belastbare Antwort auf die Frage, wer da eigentlich zugreift. Im B2B ist das komplizierter als im Consumer-Geschäft: Ihr Kunde ist keine Person, sondern eine Organisation. Die Einkäuferin darf bestellen, der Servicetechniker sieht nur Wartungsverträge, die Buchhaltung nur Rechnungen — und wenn jemand das Unternehmen verlässt, muss der Zugang zentral erlöschen, nicht in fünf Systemen einzeln.

Wir lösen das mit Keycloak, einem Open-Source-Identity-Server, den wir selbst in der EU hosten. Das ist keine exotische Wahl: Keycloak ist seit April 2023 Incubating-Projekt der Cloud Native Computing Foundation und läuft seit über acht Jahren produktiv bei Organisationen wie Accenture, CERN, Cisco und Hitachi. Zu den dokumentierten Referenzen zählen FAPI-konforme API-Autorisierung für japanische Banken und die Migration des österreichischen Unternehmensserviceportals mit über zwei Millionen Nutzern — also genau die Größenordnung „externes Portal mit vielen Organisationen“, um die es hier geht. Was Keycloak im Detail leistet, haben wir in unserem Keycloak-Guide beschrieben.

Drei Aufgaben übernimmt die Identity-Schicht im Portal: Erstens Firmenkonten mit mehreren Nutzern und einem Rollenmodell pro Kundenorganisation. Zweitens Single Sign-on — ein Login für Portal und Nachbarsysteme, auf Wunsch föderiert mit dem Verzeichnisdienst Ihres Kunden (etwa Entra ID), sodass sich dessen Mitarbeiter mit ihrem gewohnten Firmen-Login anmelden. Drittens die Mandantentrennung in der Datenbank: In unserem Stack erzwingt Supabase Row Level Security, dass Kunde A unter keinen Umständen Daten von Kunde B sieht — auf Datenbankebene, nicht nur im Anwendungscode. Warum wir genau diese Kombination einsetzen und was sie im Betrieb kostet, steht in unserem Erfahrungsbericht zum Supabase-Keycloak-Stack.

Ein Detail, das in B2B-Projekten regelmäßig unterschätzt wird: Die Identität muss an die Stammdaten des ERP gekoppelt sein. Ihre Kunden kennen ihre Kundennummer, nicht ihre Portal-User-ID. Wer beim Onboarding die Zuordnung von Portal-Konten zu ERP-Kunden- und Ansprechpartnernummern sauber modelliert, spart sich später jede Menge manuelle Freischalt-Tickets — und schafft die Grundlage dafür, dass Rollen und Freigabestufen aus dem führenden System abgeleitet werden können statt doppelt gepflegt zu werden.

Für den Datenfluss zwischen Portal und Bestandssystem gibt es keine Einheitslösung, sondern vier Grundmuster. Welches trägt, hängt weniger vom Portal ab als von zwei Fragen: Was gibt Ihr ERP heute her — und wie aktuell müssen die Daten aus Kundensicht wirklich sein? Ein Liefertermin muss stimmen, wenn der Kunde ihn abruft. Eine Rechnung von letzter Woche darf auch aus einer nächtlichen Synchronisation kommen.

In der Praxis kombinieren wir fast immer: Stammdaten und Rechnungen werden synchronisiert, der Auftragsstatus kommt live oder per Event, und alles läuft durch eine Integrationsschicht, die dem Portal eine einheitliche API anbietet. Das Portal weiß dann gar nicht, ob eine Information aus SAP, proAlpha oder einer Dateiablage stammt — und genau das ist der Punkt: Wechseln Sie das ERP in fünf Jahren, tauschen Sie einen Adapter aus, nicht das Portal.

Ein Wort zur Datenhoheit: Bei der Synchronisation entsteht eine Kopie von Kundendaten in der Portal-Datenbank. Das ist DSGVO-seitig unkritisch, wenn drei Dinge stimmen — EU-Hosting der Portal-Infrastruktur, Datensparsamkeit (nur die Felder replizieren, die das Portal anzeigt) und ein definierter Löschpfad, wenn ein Kunde ausscheidet. Alle drei Punkte gehören in die Discovery, nicht in den Nachtrag zur Auftragsverarbeitung.

Der häufigste Planungsfehler ist, die Anbindung in beide Richtungen gleichzeitig zu bauen. Lesender Zugriff — der Kunde sieht Aufträge, Rechnungen, Lieferstatus — ist risikoarm: Schlimmstenfalls zeigt das Portal einen veralteten Stand. Schreibender Zugriff — der Kunde löst eine Bestellung oder Adressänderung aus, die im ERP landet — berührt dagegen Geschäftslogik, Validierungen und im Zweifel die Buchhaltung.

Deshalb bauen wir Portale lesend-zuerst: Der erste Release zeigt Bestandsdaten und löst damit bereits die häufigsten Anrufe ab („Wo ist meine Bestellung?“, „Schicken Sie mir die Rechnung noch einmal“). Schreibende Vorgänge folgen als zweite Stufe — und dann nicht als direkter Durchgriff ins ERP, sondern als definierte Aufträge an die Integrationsschicht, die validiert, protokolliert und im Fehlerfall sauber an den Kunden zurückmeldet. Das reduziert das Projektrisiko erheblich und liefert nach wenigen Wochen einen messbaren ersten Nutzen statt nach vielen Monaten einen großen Wurf, der an der ersten fehlgeschlagenen Buchung gemessen wird.

Die Checkliste ist kürzer, als die meisten IT-Verantwortlichen erwarten. Minimum: ein Weg, Daten herauszubekommen — eine API, ein Datenbankzugriff, notfalls ein regelmäßiger Export. Das genügt für die Synchronisation und damit für ein vollwertiges lesendes Portal. Besser: eine dokumentierte Schnittstelle oder Event-Fähigkeit; dann sind Live-Daten und später schreibende Vorgänge sauber machbar. Nicht nötig: ein „webfähiges“ ERP, ein Versions-Upgrade vor Projektstart oder gar ein ERP-Wechsel. Das gilt auch für die typischen Mittelstands-Systeme jenseits von SAP — ob proAlpha, abas oder ein gewachsenes Dynamics: Entscheidend ist der Datenzugang, nicht das Alter der Oberfläche.

Das gilt ausdrücklich auch für Systeme, die intern längst als Modernisierungskandidat gelten. Ein Portal als moderne Schicht vor dem Legacy-ERP ist oft der pragmatischste erste Modernisierungsschritt: Kunden bekommen zeitgemäßen Self-Service, während das Kernsystem unangetastet weiterläuft — und die Integrationsschicht, die dabei entsteht, trägt später die schrittweise Ablösung des Altsystems. Umgekehrt gilt: Wenn Ihr eigentliches Problem der Zustand des Kernsystems ist und das Portal nur Symptombekämpfung wäre, sagen wir das im Erstgespräch — dann ist die Modernisierung das Projekt, nicht das Portal.

Zur Einordnung unsere publizierten Preisanker: Ein Kundenportal mit Rollen- und Rechtemodell und erster ERP-Anbindung liegt bei uns bei 20.000 bis 60.000 Euro. Die Spanne hängt vor allem an zwei Faktoren: wie viele Systeme angebunden werden und ob das ERP eine brauchbare Schnittstelle mitbringt oder die Integrationsschicht mehr Übersetzungsarbeit leisten muss. Ein Portal-MVP mit Keycloak-Login und einer ersten Self-Service-Funktion liegt bei 8.000 bis 20.000 Euro — oft der richtige Weg, um die Anbindung an einem echten Anwendungsfall zu beweisen, bevor die größere Investition fällt.

Stand: Juli 2026. Alle Preise netto. Die genannten Spannen sind unsere publizierten Preisanker; alle Marktzahlen sind im Text mit Quelle und Jahr attribuiert.

Wenn ein Kundenportal auf Ihrer Roadmap steht, klären Sie die Anbindungsfrage vor der Anbieterauswahl — mit drei Antworten: Welche Daten brauchen Ihre Kunden am dringendsten? Wo liegen sie? Und was gibt das führende System heute her? Diese drei Antworten bestimmen Muster, Aufwand und Zeitplan zuverlässiger als jede Featureliste. Wie wir Kundenportale entwickeln — inklusive Preistabelle und Make-or-Buy-Einordnung — haben wir offen dokumentiert. Oder wir gehen Ihre Systemlandschaft direkt gemeinsam durch: in einem kostenlosen 30-Minuten-Erstgespräch, gern mit Ihrer IT am Tisch.