Distributed Realm and Failover

[R M]

Hi

Distributed Realm is very useful

I have for example 3 different LDAPs and I'm using them because my users are distributed in that 3 LDAPs (they are not centralized)

Eg.

                <ldap-realm name="ldap1" dir-context="ldap1-connection" direct-verification="true" allow-blank-password="false" >

..

                </ldap-realm>

                                

               <ldap-realm name="ldap2" dir-context="ldap2-connection" direct-verification="true" allow-blank-password="false">

...

                </ldap-realm>

                

                <ldap-realm name="ldap3" dir-context="ldap3-connection" direct-verification="true" allow-blank-password="false">

 ...

                </ldap-realm>                                 

                <distributed-realm name="ldap" realms="ldap1 ldap2 ldap3"/>

JBOss try before on LDAP1 if it fails attempt on ldap2 and as latest attemp on ldap3

perfect

but if e.g. ldap1 is not responding because it is down ..  the distributed realm will "stop" and not continue try on ldap2 etc

I suppose a connection issue on 1 ldap is a top priority and break the chain
In my opinion this is a bug or should be better to have an option to go ahead

for this kind of exception jboss elytron manage Failover Realm..
that's fine..
but really I will need a failover based on anothre distributed real with a different order or removing one entry..
and if I have just 2 entries in Distributed Realm is simple... becasue if I will have only ldap1 and ldap2.. failover will be ldap2 and ldap1 (reversing sequence)

but with 3 or more.. impossible to manage

Do you have some idea if there is a way to manage or let the distributed realm go ahead in the chain also in case of javax.naming.CommunicationException ?

Thanks

[Diana Krepinska]

Hello,

Distributed realm does not have an option to go ahead in case of some CommunicationException because such a realm would not differentiate between a user with invalid credentials and a user trying to authenticate with valid credentials that are stored in unreachable realm. And 2 users authenticating with correct credentials might get different responses (depending on availability of the realm that they are stored in), which is not wanted. It seems better to have users backed up in separate realms and use a failover-realm for such case.

But as Farah Juma suggested in this comment, you can achieve your requirement this way:
distributed-realm[failoverRealm(ldap1, failoverRealm(ldap2, ldap3)),
        failoverRealm(ldap2, ldap3),
        ldap3
]

[R M]

Hi Diana

I believe that into a real business scenario,  a distributed realm is used just to "merge" different realm and the same credential/account are not replicated on each member of the distributed list; at least this is my personal vision

Just to give an example
a Customer have own LDAP with own users in own domain
But they want define additional account for external consulting and this customer don't want for several reason register them into own LDAP , so a simple solution is using just for example the file system realm

So "merge" both using a distributed realm is a solution

HAving LDAP as first and File System as second, we can reach the goal
but if LDAP is not responding and "consunting" need to access.. also they cannot
Of course this is a simple case and we can revert setting as first member file system and LDAP as second one (considerng no issue can occurs with the file system)
But when you have 3.. or maybe more
ana maybeso external account are declared into a separated LDAP (maybe because also connected to a VPN etc).. we are in potential trouble
My goal is to limit more than possible stopping usage of system

Failover really is a way to solve comunication issue with the credential system and for this scope failover server are "backup" of the primary (so having same definition.. at least at the time of latest sync)
(pls notes that a common practicse to define a failover on LDAP is adding list as URL)
Distributed instead is to having different subset of definitiion but logically concatenated / stack (and in case of duplicate entry, priority on list will win of course)

The option to stack multiple login modules is already available in the legacy Security Model (using sufficient flag for example on login module declaration)
As the legacy security model is soon going to be deprecated and really removed starting wildfly 25,  Elytron should have all the same features at least too assure continuity for customers
What's in case of legacy subsystem ?

example:

<security-domain name="mydomain" cache-type="default">
   <authentication>
      <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="sufficient">
         <module-option name="java.naming.provider.url" value="ldap://myldap.rh.com:389" />
      ...
      </login-module>
      <login-module code="UsersRoles" flag="sufficient">
         <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties" />
         <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties" />
      </login-module>
   </authentication>
</security-domain>

in this case LDAP is not responding (comminication exception) .. but legacy go ahead with UsersRoles Module...
if Distributed Reals is the replacement of "stack" in legacy.. so it should acts in the same way..
or there is a bug in legacy...


Based on that solution using failover.. what's in case I will need also a real failover list ?

It is just an opinion and maybe can be considered as new feature request to manage more possible business cases

regards

[Diana Krepinska]

Just to note it here as well - WFCORE-5740 was created to track adding the ability to ignore unavailable realms for a distributed-realm. Thank you for feedback!