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.
Top comments (3)
// , From my first impressions, this seems like a simple case of getting a better result by using the right tool for the job.
In this case, moving complex authentication and user provisioning logic from an authentication tool to something else.
I like seeing how you ensured that Authentication systems whose processes are tailored to Authentication don't also end up responsible for taking care of a bunch of Authorization (or as you call it here, Provisioning) processes.
Speaking of "Provisioning", what's this mean?
My search engine of choice has not yet availed me of anything that looks obviously relevant:
duckduckgo.com/?q=on-time+provisio...
duckduckgo.com/?q="on-time+provisi...
I only understand about 1/3 of what you wrote here, but what I do understand impressed me. Bravo, sir, and thanks for making our data a little more protected and our sign-up flows a little less soul crushing.
"On-time provisioning" is more or less just-in-time provisioning but earlier in the process. Provisioned ahead of time in critical systems, and still supporting the JIT scenarios as well :) I hope that clarifies it.
Clear as mud.