There is on acquisitariat a ci_authgrove database with the required tables, without any data inside:

mysql> show tables;
+------------------------+
| Tables_in_ci_authgrove |
+------------------------+
| migrations             |
| password_resets        |
| users                  |
| users_external_sources |
+------------------------+
4 rows in set (0.00 sec)

Development moratoire

Per T1771, we're currently considering implementing Keycloak as a reference identity management and SSO login product.

This product exposes a LDAP, OIDC (OpenID Connect) and SAML capabilities to authenticate users and applications. It seems to solve our main problems.

From there, it's not clear what we do with Auth Grove:

• Scenario A. We drop it, and as users we directly interact with Keycloak. Development is discontinued.
• Scenario B. Auth Grove is morphed into a front-end to use Keycloak: we expose current information, and interact with Keycloak API (through a generic set of classes to allow to switch to another solution) to set credentials and metadata.
• Scenario C. We use both Keycloak AND Auth Grove. We don't make integrate with Keycloak at all, to stay independent and not vendor-locked.

While T1771 evaluation is ongoing, a moratoire covers any development activities related to Auth Grove, with the obvious exception of security issues.
This moratoire cover fully or partly this task.