What is Elytron distributed-realm?

**Ein Elytron `distributed-realm` bündelt mehrere Security Realms zu *einem* Realm, damit Benutzer je nach Identität aus unterschiedlichen Quellen authentifiziert werden können. Praktisch heißt das: Du kannst z. B. LDAP, JDBC und Properties parallel nutzen, ohne mehrere Security Domains bauen zu müssen.** ([docs.wildfly.org](https://docs.wildfly.org/35/wildscribe/subsystem/elytron/distributed-realm/index.html)) ## Was es genau macht Ein `distributed-realm` ist für Fälle gedacht, in denen Identitäten **auf mehrere Realms verteilt** sind. Elytron behandelt diese dann als gemeinsame Quelle für Authentifizierung und Autorisierung. Die Realm-Definition enthält im Kern einfach eine Liste anderer Realms. ([docs.wildfly.org](https://docs.wildfly.org/35/wildscribe/subsystem/elytron/distributed-realm/index.html)) Der wichtige Punkt: Das ist **kein Merge aller Benutzerdaten zu einem neuen Store**, sondern eher eine **Weiterleitung/Suche über mehrere Realms**. Der Benutzer `alice` kann also in LDAP liegen, `bob` in einer Datenbank und `admin` in einer Properties-Datei. ([docs.wildfly.org](https://docs.wildfly.org/40/WildFly_Elytron_Security.html)) ## Wann du es brauchst Du brauchst `distributed-realm`, wenn du **mehrere Identity Stores gleichzeitig** verwenden willst und diese Stores **dieselben Benutzer nicht zwingend alle enthalten**. Typische Fälle sind Migrationen oder Mischbetrieb: - alte lokale Admin-Accounts in `properties-realm` - normale Mitarbeiter in `ldap-realm` - Anwendungsnutzer in `jdbc-realm` ([docs.redhat.com](https://docs.redhat.com/en/documentation/red_hat_jboss_enterprise_application_platform/8.1/pdf/securing_applications_and_management_interfaces_using_multiple_identity_stores)) Der praktische Vorteil ist vor allem bei Migrationen groß: Du kannst neue Benutzer schon gegen LDAP prüfen, während Alt-Benutzer noch lokal existieren. ## Wichtiger Unterschied zu typischen Fehlannahmen `distributed-realm` ist **nicht** dasselbe wie „ein Realm mit Fallback für Rollenmapping“. Entscheidend ist die **Verteilung der Identitäten** über mehrere Realms. Wenn derselbe Benutzer in mehreren Stores existiert, wird das Design schnell heikel, weil dann **Reihenfolge und Auflösung** relevant werden. Für saubere Setups sollte ein Benutzer idealerweise **genau in einem** der beteiligten Realms liegen. Das ist der Punkt, den viele kurze Erklärungen in Suchergebnissen nicht klar genug sagen. Die Funktion ist stark für **partitionierte Benutzerbestände**, weniger für chaotische Überschneidungen. Diese Einordnung folgt aus der offiziellen Beschreibung „identities distributed between multiple realms“ und den Konfigurationsbeispielen. ([docs.wildfly.org](https://docs.wildfly.org/35/wildscribe/subsystem/elytron/distributed-realm/index.html)) ## Beispiel In WildFly sieht das typischerweise so aus: ```cli /subsystem=elytron/distributed-realm=distributedRealmExample:add(realms=[properties-realm,ldap-realm,jdbc-realm]) ``` Danach bindest du dieses Realm in eine `security-domain` ein. Genau dieses Muster zeigen die offiziellen WildFly- und EAP-Dokumentationen. ([docs.wildfly.org](https://docs.wildfly.org/40/WildFly_Elytron_Security.html)) ## Praktisch wichtig Ein oft übersehener Punkt ist `ignore-unavailable-realms`: Damit kann ein `distributed-realm` weiterarbeiten, wenn einzelne Backends zeitweise nicht erreichbar sind. Das ist in produktiven Umgebungen relevant, weil sonst ein einzelner ausgefallener Store die gesamte Anmeldung stören kann. ([wildfly-security.github.io](https://wildfly-security.github.io/wildfly-elytron/blog/tag/distributed-realm/)) Wenn du es in einem Satz einordnen willst: **`distributed-realm` ist die richtige Wahl, wenn Benutzer absichtlich auf mehrere Identity Stores verteilt sind; für überlappende oder fachlich unsaubere Benutzerquellen ist es meist nicht die beste Lösung.** ([docs.wildfly.org](https://docs.wildfly.org/35/wildscribe/subsystem/elytron/distributed-realm/index.html))