Requirements:

• All user-relations are to be centralized for GDPR reasons.
• Be able to create a ticket with an on-time provisioned user in remote system.
• User must be able to be on-time provisioned at login time.
• User experience during login process cannot deteriorate.

Login process

We use Auth0 currently in our infrastructure to authenticate and authorize users. Now Auth0 allows something called rules to execute in the login process before passing on the JWT back to the calling application. There are some limitations to this. Per rule there is a limit on amount of ms of execution time before the rule is discarded. There is also a limit on the total amount of seconds before the entire rulechain is discarded.

So adding more into the rule chain to be executed synchronously/awaited async calls, will increase the total login time for a user.

The process itself is without any meaningful or informative graphics or copy telling them what is happening. Just a short loader and a bunch of redirects and stalled pages.

Improvement

So here we can improve things. Not only can we scale down the rule-chain into bare essentials and offload everything else into a queue/service-bus/event-hub/etc (Azure Service Bus) and we could do websocket/long-running polls (SignalR) to get status updates on the login process, it wouldn't matter how much we add into it, but the user gets to know that we're doing something. Even if we're not explicitly telling them exactly what, they get something pretty to look at before we return them to the calling application.

So now we can ensure any number of remote systems being able to get auto-created users if they are not already created.

The rest of the owl...

The same system then, that is listening to the queue, also has API endpoints exposed to manually fire off requests with payloads saying things like "take this user's JWT, create the user in system X in country Y" and the abstraction in that auto-provisioning API will handle it.

Not particularly ground breaking since these kinds of loaders are quite abound, but considering the backend systems we have to deal with, it's a nice upgrade.

Summary

The first part is solved where we can maintain the already established centralized user-store.

The second and third parts are solved by being able to initiate remote system synchronization/on-time-provisioning through it's integration layer either through a queue or direct API calls.

And the fourth part is solved by that SignalR enabled spinner-app that awaits user to be fully finished with their login process by listening/watching that signoff of the user in the event-stream.