Keeping data in sync between IdentityServer and application

Question

I use IdentityServer4 (with Asp.Net Core Identity) as a centralized auth point for multiple applications.

In one of the applications I want to setup a scheduled job to send out e-mail notifications to multiple users. When the job will execute, it will have no access to user claims (as it will execute not in the context of a single user request) and thus there will be no place to read user's e-mail from. This means I will have to duplicate e-mails in the application DB.

But how to keep e-mails in sync between the app and the IdentityServer if some user wants to change it?

Answer 1

A good approach would be to implement integration events in your system. This is a mechanism that raises an event 'This special thing happend', and allows other parts of your system to be notified.

You can use RabbitMQ or Azure ServiceBus for example to send messages to. Every system being subscribed to that kind of message, will receive it.

So in your case, you would create an event called UserChangedEmailAddressIntegrationEvent for example. Then in your emailing system, you subscribe to exact this event. Once it's raised, your emailing system will receive the message and be able to handle it.

The UserChangedEmailAddressIntegrationEvent could in fact be a class, containing (for example) two properties, OldEmail and NewEmail so the emailing system knows what value to change.

See the eShopOnContainers example project, which has this exact technique implemented https://github.com/dotnet-architecture/eShopOnContainers

Answer 2

We have faced a similar problem where we had Hangfire jobs running that would extract reporting data from our system and then email the reports to the set of users configured when creating the scheduled job.

We also used Identity Server 4 with ASP.Net Identity and ended up storing the user id's on the scheduled job info. We then also created an api endpoint on our ASP.Net Identity that would serve back the required user info given user id (or a list of user id's). Lastly, we used client_credentials and created a client to consume that api during the job execution that would retrieve appropriate user info at a given point in time from our ASP.Net Identity api.

Such approach has worked well for us so far and it removed the pain of having to think about how to ensure data syncing all together.