We want to register users:
- by offering a registration form
- through external authentication sources
- by provisioning
- by API
- from CLI
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T270 Implement SSO on forum.nasqueron.org | |||
| Open | None | T271 Deploy Auth Grove to login.nasqueron.org | |||
| Open | None | T345 Add registration capabilities | |||
| Resolved | dereckson | T346 Offers an UI to register an account | |||
| Open | None | T343 Provide a migration path from Espace Win accounts to Nasqueron accounts | |||
| Open | None | T347 Allow to register an account through a social login | |||
| Open | None | T348 Allow user accounts provisioning | |||
| Wontfix | dereckson | T349 Add Wikimedia OAuth2 registration capability | |||
| Open | None | T366 Implement mailcheck to check current mail error at register time | |||
| Open | None | T478 Validate e-mail addresses |
Event Timeline
Comment Actions
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.