Querschnitt · Prio 9 · Version 4

Identity / Security / LDAP / SSO

Authentifizierung, Autorisierung, Rollen, technische Benutzer, Zertifikate, SSO, Audit und Berechtigungsmigration.

← Startseite
Kurzverständnis und Systemgrenze

Legacy-Security besteht haeufig aus LDAP-Gruppen, JAAS-Konfiguration, Containerrollen, SSO, technischen Benutzern, Zertifikaten, Firewallregeln und hart codierten Sonderpruefungen.

Die Herausforderung liegt in der Uebersetzung: Eine LDAP-Gruppe ist nicht automatisch eine fachliche Rolle. Eine Containerrolle ist nicht automatisch eine Berechtigung fuer einen konkreten Geschaeftsfall.

Modernisierung muss Authentifizierung, Autorisierung und Audit trennen. Ziel ist ein klares Rollen- und Berechtigungsmodell, das in neuen Anwendungen, APIs, Batchjobs und Integrationen konsistent verwendet wird.

Daten- und Verantwortungsgrenze: Security ist ein Querschnittssystem, aber fachliche Berechtigungen gehoeren dem Unternehmen. Technische Gruppen in LDAP sind nur die Implementierung. Bei Modernisierung muessen Rollenmodell, Auditpflicht und Berechtigungsfreigabe erhalten bleiben.
Fachliche und technische Darstellung
Fachliche Sicht Identity / Security / LDAP / SSO
Fachliche Sicht: Prozess, Verantwortung, Nachweis.
Technische Sicht Identity / Security / LDAP / SSO
Technische Sicht: Komponenten, Protokolle, Betriebsbezug.
Wichtige Begriffe und Artefakte

Authentication

Nachweis, wer oder was zugreift.

Authorization

Entscheidung, was diese Identitaet tun darf.

RBAC

Rollenbasierte Berechtigungen.

ABAC

Attributbasierte Entscheidung, zum Beispiel Mandant, Betrag, Region oder Risikoklasse.

Typischer Ablauf Schritt für Schritt
  1. Benutzer authentifiziert sich ueber SSO oder Containerlogin.
  2. Anwendung liest Gruppen/Rollen aus LDAP oder Token.
  3. UI zeigt Aktionen abhaengig von Rolle und Fachstatus.
  4. Service prueft Berechtigung erneut serverseitig.
  5. Audit schreibt wer, wann, was, warum und mit welchem Ergebnis.
Ausführliche Praxisbeispiele mit Code und Konfiguration

Die Beispiele sind bewusst nicht minimalistisch. Sie zeigen typische Artefakte, die man in echten Legacy-Analysen findet: Schnittstellenverträge, Containerkonfiguration, SQL/PL-SQL, Jobdefinitionen, Queue-Regeln oder Adaptercode.

LDAP-Gruppe als technische Implementierung
dn: cn=billing-approver,ou=groups,dc=example,dc=com
objectClass: groupOfNames
cn: billing-approver
description: Darf Rechnungen bis definierte Betragsgrenze freigeben
member: uid=apolat,ou=people,dc=example,dc=com
web.xml Security Constraint
<security-constraint>
  <web-resource-collection>
    <web-resource-name>Invoice Approval</web-resource-name>
    <url-pattern>/invoice/approve/*</url-pattern>
  </web-resource-collection>
  <auth-constraint>
    <role-name>BILLING_APPROVER</role-name>
  </auth-constraint>
</security-constraint>
<security-role>
  <role-name>BILLING_APPROVER</role-name>
</security-role>
Policy Service fuer moderne Autorisierung
public class AuthorizationPolicy {
    public void requireInvoiceApproval(User user, Invoice invoice) {
        if (!user.hasPermission("invoice.approve")) {
            throw new AccessDeniedException("missing permission invoice.approve");
        }
        if (invoice.amount().isGreaterThan(user.approvalLimit())) {
            throw new AccessDeniedException("approval limit exceeded");
        }
        if (!user.canAccessTenant(invoice.tenantId())) {
            throw new AccessDeniedException("tenant not allowed");
        }
    }
}
Risiken, Fehlerbilder und Diagnose
AspektBeschreibung
Fachliches RisikoUnklare Verantwortung fuer Benutzerrolle fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem.
Technisches RisikoLDAP und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen.
BetriebsrisikoFehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert.
MigrationsrisikoNeue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern.
Typische Fallen:
  • Berechtigungspruefung nur in UI, nicht im Service.
  • Technische Accounts haben zu breite Rechte und keine Rotation.
  • LDAP-Gruppen werden 1:1 in neue Rollen kopiert, ohne fachliche Bereinigung.
  • Auditlog speichert Aktion, aber nicht fachlichen Kontext oder Ablehnungsgrund.
Modernisierungspfad und geeignete Entwurfsmuster
PatternEinsatz in diesem System
Strangler Fig PatternNeue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen.
Anti-Corruption LayerAltbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen.
FacadeKomplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln.
AdapterProtokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen.
Golden Master TestBestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen.
Empfohlene Schritte:
  • Erstelle Rollen-Berechtigungs-Matrix mit fachlichen Besitzern.
  • Trenne Authentication Provider von Authorization Policy.
  • Fuehre zentrale Policy-Pruefung mit testbaren Regeln ein.
  • Migriere technische Benutzer mit Secret-Rotation, Least Privilege und Zertifikatsinventar.
Analysefragen für echte Projekte
  • Wer besitzt fachlich die Wahrheit fuer Benutzerrolle?
  • Welche technische Komponente ist kritisch: LDAP, JAAS, SAML?
  • Welche Daten werden veraendert, gelesen, abgeleitet oder nur transportiert?
  • Welche Fehler sind fachlich erwartbar und welche sind technische Stoerungen?
  • Welche Protokolle, Dateien, Tabellen, Queues oder Reports bilden den offiziellen Vertrag?
  • Wie wird ein Fehler heute erkannt, korrigiert und gegenueber dem Fachbereich nachgewiesen?
  • Welche Teile lassen sich lesend modernisieren und welche sind schreibend hochkritisch?
  • Welche Tests sichern aktuelles Verhalten, bevor Refactoring oder Migration beginnt?
Übung

Erstelle eine Matrix aus fachlicher Rolle, LDAP-Gruppe, erlaubter Aktion, Bedingung, Auditnachweis und technischem Zielmodell. Markiere Rollen, die vor Migration fachlich bereinigt werden muessen.

⌂ Cockpit