Ein Login auf der Website zu bauen ist einfach. Ein richtiges Kundenportal zu bauen, ist eine andere Sache.
Eine Website zeigt Inhalte. Ein Portal verwaltet Beziehungen, Zustaende, Berechtigungen, Transaktionen. Das klingt abstrakt, wird aber konkret bei der ersten Frage: Wer darf was sehen, und was passiert, wenn jemand etwas sieht, das er nicht sehen sollte?
Das ist kein theoretisches Szenario. Es ist im schlechten Fall ein Datenschutz-Vorfall.
Rollen- und Rechtemodell als Herzstueck
In Kundenportalen gibt es selten den einen Nutzer, sondern Aussendienst, Innendienst, Teamleiter, Admins, jeweils mit unterschiedlichen Sichten. Der haeufigste Fehler: Rollen werden zu grob oder zu granular definiert. Sobald verschiedene Kundengruppen, Unterkonten, Freigabeprozesse oder Mandantentrennung existieren, braucht es ein durchdachtes Berechtigungsmodell, das serverseitig validiert wird, denn was das Frontend nur ausblendet, ist kein Sicherheitsmerkmal.
Auth selbst bauen oder einkaufen
Auth selbst zu implementieren ist riskant, nicht wegen fehlender Kompetenz, sondern weil Auth viele Edge Cases hat, die erst bei Problemen sichtbar werden. Fuer die meisten Projekte lohnt sich ein Auth-Provider wie Keycloak, Auth0 oder Supabase, waehrend sich das Team auf die Applikationslogik konzentriert.
Audit-Log als Pflicht, nicht als Kuer
In vielen Portalen ist ein Audit-Log aus Compliance-Gruenden oder schlicht fuer den Kundenservice notwendig, um nachzuvollziehen, wer wann was veraendert hat. Das von Anfang an mitzudenken ist deutlich einfacher, als es nachtraeglich zu ergaenzen.
Skalierung und Mandantentrennung
Verschiedene Kunden sehen nur ihre eigenen Daten, geloest entweder auf Datenbankebene mit einem eigenen Schema pro Mandant oder auf Applikationsebene per Tenant-ID-Filtering. Beide Ansaetze haben Vor- und Nachteile, die von Skalierungsanforderungen abhaengen.
Checkliste: Rollen- und Rechtemodell dokumentiert, serverseitige Autorisierung fuer alle Endpoints, Auth-Provider gewaehlt, Audit-Log konzipiert, Mandantentrennung-Strategie definiert, Datenschutzkonzept fuer Portaldaten vorhanden.
Ein Beispiel aus der Praxis
Ein Kundenportal wurde urspruenglich mit einem einfachen Rollenmodell aus Admin und Nutzer gebaut. Als ein Grosskunde mit mehreren Unterkonten und eigenem Freigabeprozess hinzukam, stiess dieses Modell an seine Grenzen: Wer durfte im Namen des Unternehmens Bestellungen freigeben, und wer nur einsehen? Die nachtraegliche Einfuehrung eines granularen Rechtemodells kostete deutlich mehr Aufwand, als es von Anfang an gekostet haette. Seither wird bei jedem neuen Portal-Projekt das Rechtemodell bewusst fuer den komplexesten erwarteten Kundentyp entworfen, nicht fuer den einfachsten.
Kundenportal geplant? markom.digital entwickelt Portale, die sicher, skalierbar und nutzbar sind, von der ersten Anforderung bis zum Live-Betrieb.
