Authentication
Nachweis, wer oder was zugreift.
Authentifizierung, Autorisierung, Rollen, technische Benutzer, Zertifikate, SSO, Audit und Berechtigungsmigration.
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.
Nachweis, wer oder was zugreift.
Entscheidung, was diese Identitaet tun darf.
Rollenbasierte Berechtigungen.
Attributbasierte Entscheidung, zum Beispiel Mandant, Betrag, Region oder Risikoklasse.
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.
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
<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>
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");
}
}
}
| Aspekt | Beschreibung |
|---|---|
| Fachliches Risiko | Unklare Verantwortung fuer Benutzerrolle fuehrt zu widerspruechlichen Entscheidungen zwischen Alt- und Neusystem. |
| Technisches Risiko | LDAP und angrenzende Komponenten werden isoliert betrachtet; Laufzeitkopplung bleibt verborgen. |
| Betriebsrisiko | Fehlerkanal, Monitoring, Restart oder manuelle Klaerung sind nicht ausreichend dokumentiert. |
| Migrationsrisiko | Neue Architektur uebernimmt Daten oder Schnittstellen, ohne fachliche Invarianten und historische Sonderfaelle abzusichern. |
| Pattern | Einsatz in diesem System |
|---|---|
| Strangler Fig Pattern | Neue Funktionalitaet vor das Altsystem setzen und Altanteile schrittweise herausloesen. |
| Anti-Corruption Layer | Altbegriffe, technische Codes und Datenformate vom neuen Domänenmodell trennen. |
| Facade | Komplexe Legacy-Operationen hinter klaren fachlichen Use-Case-Methoden kapseln. |
| Adapter | Protokolle und Formate wie SOAP, MQ, Copybook, SQL oder File in Ports uebersetzen. |
| Golden Master Test | Bestehendes Verhalten mit Referenzdaten erfassen und gegen neue Implementierung vergleichen. |
Erstelle eine Matrix aus fachlicher Rolle, LDAP-Gruppe, erlaubter Aktion, Bedingung, Auditnachweis und technischem Zielmodell. Markiere Rollen, die vor Migration fachlich bereinigt werden muessen.