Syncing Auth Systems With Spotty Connectivity

Hiya,

I ran into an interesting niche use case a few weeks ago. Imagine you are disconnected from the internet, yet still have a local area network including applications you want users to log into using standard web protocols like OIDC and SAML. This is called an air-gapped system. The network breaks can be physical or use software such as firewalls. The former is more secure and suitable for highly sensitive data.

In certain circumstances, internet may be available but spotty or costly. For instance, if you are on an airplane or on a cruise ship, you may have access to slower internet. The latency may be large enough that accessing servers over the internet is painful.

Let's consider a cruise ship. Users on the ship want to access apps for ordering massages or watching entertainment using a fast local network. The cruise ship company needs users to log in to access the apps, and use the same credentials they did when they booked the cruise.

A remote authentication server offers a poor user experience in this situation. Instead, if you set up a local auth server to handle user authentication and registration for the internal apps and the entire network, users will be able to login easily. User data can be populated by replicating data from the primary, remote authentication server to this local server when the ship is leaving port. This can be done for all the customers on the cruise ship, but no others.

Linking accounts in this way shifts the source of truth, but gives the user one view of their account, whether they are on land or at sea. They can make changes wherever they are.

But you have to capture changes; this is more complicated than you might think. You can either:

• use a remote auth server, running on the internet; this is subpar because of the latency but removes the synchronization problem

• sync the local and primary servers when there is sufficient connectivity, such as when a cruise ship gets into port or when the cruise is finished

Syncing data between different sources of record is always tough. You should consider the following scenarios for changes to user data.

• neither the local nor remote data change; the user logs in on the cruise ship but doesn't change their profile data

• the local data changes; a user changes their plan or password on the cruise ship

• the remote data changes; a user is automatically upgraded to a different plan based on their credit-card points

• both the local and remote data change; a user updates their preferences on the cruise ship and a family member on land resets the account password

The first challenge, of course, is knowing which of these scenarios is true for each user account. You can look at last update timestamps; another option is to hash relevant profile data and then compare the hashes. You need to do this comparison for the users on the cruise ship when no further changes are possible, such as when the ship docks.

Once you know whether there were changes, you need to take action to merge the data. However, in the first case, no syncing needs to happen, since there are no changes.

In the second and third cases, the system with the changes usually "wins". When the local data changes, you need to push the changes up to the primary. When the remote data changes but the local data does not, you can throw away the local data. There may be situations where the remote data should win even if the local data is newer, such as when the remote data was updated not by user action but by an automated system.

In the fourth case, you need to merge the data. How to do this depends on the data and the metadata you have about it. As above, there might be data that the remote auth server should always control. Often the last possible value should win, such as with credentials. And there might be data that should be merged, such as preferences or consents.

Any data entered by the end user with conflicts can be surfaced for human review by the user. For instance, if there drink preferences are updated in both systems, the software can ask the user what they prefer.

There is a data structure useful for conflict resolution. It's called the "conflict-free replicated data type". I'm not aware of any CIAM system that implements this data structure, probably because this kind of replication is a niche problem.

So if you are in this situation you'll be writing business logic to determine what attributes from each data source should "win" and merging them.

An alternative is to force one auth system be read only for the set of users on the cruise ship, essentially migrating the source of truth. Since you know the list of users, you can do the following:

• copy their account to the local server

• disallow changes to these accounts on the remote, primary server

• when the cruise is done, copy the account changes all back up to the primary server

New accounts would be pushed up to the primary. But conflicts could still occur. If you allow for self-service registration, it is possible that a new local account could conflict with an existing account in the primary server. You'd want to handle that, because there might be account takeover issues if you by default let the local account "win". Or you could copy all the accounts from the primary to the local, which would remove the conflict issue, but might cause other issues such as a need to support account recovery without great access to the internet for checking for a "forgot password" email.

If I were to start looking at this problem, I'd start with the needed functionality. Are you looking to allow:

• login

• registration

• profile data update

• or some combination of the three?

Then I'd examine the profile and credential data, seeing if any is immutable and what might change based on user or system actions. Finally, I'd plan for merging the two data sets, including handling merge conflicts.

Super business specific, super niche, but super nerdy and interesting.

Cheers,

Dan