Webhook/API support for syncing directory data and account confirmations

[jgknight]

Description of the Feature

There are several areas where RAS would benefit by being able to sync data and offload certain functions to the frontend/service provider.

• Handling of confirming AIM accounts (sending email)
• Handling of updating/confirming email address (also sending email)
• Syncing of name, email address, other directory information between RAS and the frontend

Ideally we would avoid putting any functionality such as sending emails into RAS itself. The expectation is that the service provider will have infrastructure already in place to send email.

Using ChivaNet as an example here - the service has its own account manager with a profile that can store information such as an email address, name, etc. If a user updates their name or email address on AIM (via RAS) then we'd want to

1. Push data from RAS to ChivaNet
2. But also respect ChivaNet's existing validation policies
3. Also support pushing data from ChivaNet to RAS via the mgmt API (just to keep in mind, we want to avoid any potential syncing loops!)

Since we don't really expect service providers to build their service around the RAS database directly, it may be useful to provide a webhook/API interface to this sync mechanism.

Use Case

The service provider would configure a URL in RAS that would be used to push changes from RAS-> to the API. When a user changes a field such as their email address in RAS, this webhook or API URL would be called by RAS with the updated data. Upon a successful response RAS would then proceed with the change as a success and update its own database. Upon a failure response, RAS would reject it with an error back to the end user.

Similarly, if RAS needs to take an action such as sending a confirmation email, a URL could be used to notify the frontend service provider to handle the emailing and account confirmation process.

When a user updates their email address, the old AIM service would have that email update pending until the user clicked on a confirmation link in their email.

Potential Challenges

• We would need to provide an API contract that the provider can build around
• Configuration and implementation is left as an exercise to the service provider and could be somewhat complicated
• There will be a limit to the data that can sync, for example passwords, because we're at the mercy of what the old AIM clients implemented/supported

Additional Information

We would want to make all of this optional so that a service provider can just rely on RAS and its database alone without syncing or having email handling.