Handling outcome of async organization member invite flow #41086
Unanswered
apacurariu
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello everyone,
As the POST /admin/realms/{realm}/organizations/{org-id}/members/invite-user endpoint is inherently async and merely returns 204 No Content, what is the best practice to determine the ultimate outcome of the user registration process that is triggered by this endpoint?
In my specific application, and I imagine my case is not unique, user invitations are programmatically managed via the endpoint discussed above, and, once a user registers, the application must provision user-specific resources before the user can effectively use the app.
The non-organization user creation endpoint (POST /admin/realms/{realm}/users) returns 201 Created instead of merely 204 No Content, so the calling application receives the user id for the newly created user. On the other hand, the organization-based invitation flow is asynchronous and it's unclear what the best practice for application-level user-specific resource provisioning is in this case.
As a thought, might I suggest that the API endpoint should return 202 Accepted with the user id that would ultimately be assigned to the user upon registration completion? This might require Keycloak to internally manage outstanding invitations and pre-allocate user ids but it would make life much easier for applications using the /invite-user flow. These apps could create their own user record with the same Keycloak user id and begin provisioning user-specific resources even before the user registration flow completes. Should the user abandon, forget or encounter errors in completing registration, the application admin could simply send the user a new registration link.
Under the current API contract, the application cannot know whether registration completed and when. The only way I see for completing this async process is by implementing a custom Event Listener SPI that listens for the REGISTER event and communicates with the application on a backchannel (e.g. message queue). This is doable but introduces additional complexities around consistency, delivery guarantees and more moving parts so I'm wondering if there's a better solution I'm not familiar with.
Much appreciated!
Beta Was this translation helpful? Give feedback.
All reactions