Was ist ein Elytron Aggregate-Realm?

**`aggregate-realm` in Elytron kombiniert zwei Aufgaben, die oft getrennt liegen: Es authentifiziert einen Benutzer gegen *ein* Realm und lädt Rollen/Attribute für die Autorisierung aus *einem oder mehreren anderen* Realms.** Das ist genau dann sinnvoll, wenn Passwörter z. B. in einer `properties-realm` liegen, Gruppen oder Rollen aber in LDAP oder einer Datenbank. ([docs.wildfly.org](https://docs.wildfly.org/26.1/wildscribe/subsystem/elytron/aggregate-realm/index.html)) ## Was es konkret macht Bei einem `aggregate-realm` gibt es zwei Phasen: 1. **Authentifizierung** `authentication-realm` prüft Credentials, also Passwort oder andere Nachweise. 2. **Autorisierung** `authorization-realm` oder `authorization-realms` lädt die Identität für Rollen, Gruppen und weitere Attribute. Bei mehreren Authorization-Realms werden die Attribute zusammengeführt. ([docs.wildfly.org](https://docs.wildfly.org/26.1/WildFly_Elytron_Security.html)) Der praktische Effekt ist wichtig: **Der Benutzer meldet sich nur einmal an, aber Elytron kann Identitätsdaten aus mehreren Quellen zusammensetzen.** Das spart oft eine aufwendige Migration in einen einzigen Identity Store. ([docs.wildfly.org](https://docs.wildfly.org/26.1/WildFly_Elytron_Security.html)) ## Typischer Einsatzfall Ein klassisches Beispiel ist: - Passwort in `properties-realm` - Rollen in `jdbc-realm` oder `ldap-realm` Dann prüft WildFly erst das Passwort im ersten Realm und holt danach die Berechtigungen aus dem zweiten. Genau dieses Muster zeigen die WildFly-Dokumente auch als Standardbeispiel. ([docs.wildfly.org](https://docs.wildfly.org/38/WildFly_Elytron_Security.html)) ```bash /subsystem=elytron/aggregate-realm=combined:add( authentication-realm=properties-realm, authorization-realm=jdbc-realm) ``` ## Wichtiger Unterschied zu ähnlichen Realms `aggregate-realm` ist **nicht** dasselbe wie ein `distributed-realm` oder `failover-realm`. - **`aggregate-realm`**: trennt Authentifizierung und Autorisierung bewusst. - **`distributed-realm`**: sucht Identitäten verteilt über mehrere Realms. - **`failover-realm`**: nutzt einen Ersatz-Realm bei Ausfall. ([docs.wildfly.org](https://docs.wildfly.org/34/WildFly_Elytron_Security.html)) Der entscheidende Denkfehler in vielen Erklärungen ist: Man erwartet oft, dass alle Realms gleichberechtigt für Login und Rollen genutzt werden. **Genau das macht `aggregate-realm` nicht.** Es hat eine klare Hauptquelle für die Anmeldung und getrennte Quelle(n) für Berechtigungen. ([docs.wildfly.org](https://docs.wildfly.org/26.1/wildscribe/subsystem/elytron/aggregate-realm/index.html)) ## Noch wichtig `authorization-realm` und `authorization-realms` sind gegenseitig ausschließend; du nutzt also entweder genau einen Authorization-Realm oder eine Liste davon. Optional kann zusätzlich ein `principal-transformer` den Benutzernamen zwischen Authentifizierung und Attribut-Lookup umschreiben, etwa wenn Login-Name und LDAP-Name nicht identisch sind. ([docs.wildfly.org](https://docs.wildfly.org/26.1/WildFly_Elytron_Security.html)) Die kurze Experteneinschätzung: **`aggregate-realm` ist die richtige Wahl, wenn du bestehende Identity Stores weiterverwenden willst, statt Benutzer, Passwörter und Rollen künstlich in ein einziges Backend zu pressen.**