Support for failover JDBC realms in Elytron?

[spacegoat]

I have two sites, each site has a host controller and a non-XA datasource. Via the database bi-directional multi-master replication is being performed to keep the data on both sides consistent. My application running is clustered and I would like the authentication/authorization process to fail to my secondary datasource if the first one is down.

Currently...

• I have two JDBC realms defined (these are verified working, if I manually configure them as the default realm in the security domain).
• I have one security domain defined that uses one of the JDBC realms as the default realm
  • In the "realms" configuration for the security domain, I have both JDBC realms defined

Given the above setup, only the default realm will be contacted for authentication/authorization. The secondary JDBC realm is not contacted if the primary is unavailable.

I assume this is a supported setup, it worked with WildFly 10 before I used Elytron - what can I do to fix this in Elytron?

[mchoma]

This is not supported directly in Elytron [1]

Which DB do you use? Could you workaround using failover with jdbc driver url? For example Oracle driver has possibility to connect to RAC by defining multiple nodes to connect. If one is unavailable another is tried.

[1] [JBEAP-8909] Elytron insufficiently covers scenarios with more user storages - Realm Failover - JBoss Issue Tracker

[dlofthouse]

Is there any difference between the two JDBC realms? Is this fail over to an exact replica on a different server?

[mchoma]

spacegoat Can you answer Darran's question. If we will understand your need, it can be implemented in future

[spacegoat]

Hey, sorry about the delay in response!

There's no difference between the JDBC realms other than their names. The failover is to an exact replica on a different server, yes. In fact it's using bi-directional replication between the two databases to ensure the content is the same.

[spacegoat]

The DB is PostgreSQL.

[mchoma]

I believe this specific situation should be solved on DB level [1] not on security framework level.

Probably some support on /subsystem=datasources would be also reasonable, but I can't say for sure.

How do you solve this for rest of applicaiton (aside of authentication)?

[1] https://www.postgresql.org/docs/9.2/static/high-availability.html

[spacegoat]

That's a great question, the answer at this point is, "my solution is still in progress". See my latest question posed as it's entirely related to what you asked: Client config for HA EJB RMI

From my theoretical current perspective though, my plan was to hold configurations to each host controller within the client application. On specific exceptions related to connection failure, try another destination (failover) with the failed invocation. The clustering and DB bi-directional replication would provide the underlying support for displaced invocations (i.e. host controller X is unresponsive, so host controller Y was used (data and state is the same thanks to DB replication and Infinispan)).

This problem with the authentication piece, however, means that if the primary realm is down, I have to change the Wildfly profile (a manual action assuming I didn't deploy some hacky script to cron) to prefer the secondary realm to get authentication back up. This isn't the end of the world or anything, but it was a capability of the WildFly 10 security system.

The DB driver approach is an interesting perspective, I hadn't considered that as a workaround. I'll look into that, thanks!