Add user.externalId to the user object and allow DB selects/Fuzzy Search on this field value

[jobannon]

Add user.externalId to the user object and allow DB selects/Fuzzy Search on this field value

Problem

When not using the ElasticSearch, linking a user from FusionAuth to an external system for synchronization reasons can be difficult.

Solution

Add a fuzzy searchable field on the user using a regular DB engine and FusionAuth

Alternatives/workarounds

Consider syncing external systems using the user.id field.

Due to integration restrictions, this is not always available as an option.

Additional context

Internal -> https://inversoft.slack.com/archives/C02Q208MSNP/p1671580612958709

related issue: #1516

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[benkloester]

Thanks for raising this.

When not using the ElasticSearch, linking a user from FusionAuth to an external system for synchronization reasons can be difficult.

We are linking on employee-id, which we are currently storing as a field in user.data. This means that we can only retrieve the User via ElasticSearch

Using ElasticSearch would be fine if it were guaranteed to return an up-to-date User object. The trouble is we are experiencing race conditions when using ES:

1. Our event handler processes an event changing some user attribute. It retrieves the User via ES using employee-id, changes the attribute and PUTs the modified User object (we are not using PATCH because in some cases we need to nullify values which PATCH cannot do)
2. Very soon after, it processes another change event for the same user. It retrieves the User via ES, but the User returned hasn't yet been updated from 1), so when we PUT the user reflecting the change from event 2), it clobbers the change from event 1)

[benkloester]

The other option floated to address the above was to add the equivalent of refresh=wait_for to your Search API.

This is probably less effort for you than implementing support for external ids and would address the race conditions outlined above (though at the expense of latency).