Support for webhooks for sign up control
Created by: RafLeszczynski
Based on the following RFC: https://docs.google.com/document/d/1bNL1zVoWO3wpi3z83kajHtBZ5sKZxEC_9P3CTKuPB5w/edit?usp=sharing
Currently there is no easy way for our customers to extend the existing authorization facilities in the auth/z space. Users can login with different identity providers, but customers cannot define their own logic to control which users are allowed to login or sign up to use sourcegraph.
We also have no way to support controling which users are allowed to login or sign up for generic OpenID Connect or OAuth2 auth providers.
An easy extension point would be a webhook that is called in the authorization pipeline. The flow would look as following:
- Users successfully logs in with an identity provider
- Authorization pipeline is started
- If there is a custom webhook configured in site config, a call is made to the webhook
- If the webhook returns HTTP 200, the authorization was successful and user can sign in / sign up
- Otherwise a. the authorization pipeline returns an HTTP 403 b. the user account is marked as disabled/inactive in the database (this way the user account no longer consumes a seat in the license)
To support the above, we need to achieve the following:
-
Figure out how we want to authorize the webhook calls themselves. Webhook is going to receive user data, so we need to make sure we are not calling random URLs and at the same time the webhook must be able to verify that sourcegraph is giving the data and not some attacker. For example stripe does it by signing the webhook calls and verifying the signature -
Make the necessary changes to site config to support this flow -
Make the necessary changes to the code, so that the webhook is called and user data is sent over -
React on the webhook call result - return 403 if the webhook call fails and mark the user account as inactive in the DB -
Change how we count active users for the license, so that inactive accounts are not being counted