Enterprise sign-in for organizations: SAML/OIDC, SCIM, MFA, and session policy

[giswqs]

Summary

Institutional sign-in for organizations: SAML 2.0 and OpenID Connect federation, SCIM provisioning, multi-factor authentication, and administrable session and password policy.

Why

This is the last mile of the access-control work, and the one that decides whether a university, agency, or company can deploy GeoLibre at all rather than by exception. Institutional IT will not adopt a tool that requires a separate credential per person and offers no way to deprovision.

Concretely, the requirements that show up in every procurement conversation:

• Federated login. People sign in with the institutional identity provider. A GeoLibre-specific password is a policy violation in many places, not a preference.
• Deprovisioning. When someone leaves, access ends everywhere, without an administrator remembering to remove them from each group and project. Manual removal is not an acceptable answer at any real headcount.
• MFA. Usually mandated, and usually satisfied by the identity provider once federation exists — which is a good reason to do federation first.
• Session policy. An idle timeout, a maximum session lifetime, and forced re-authentication for administrative actions.

None of this is meaningful before organizations exist, which is why it belongs last.

Proposal

1. Enterprise logins

• SAML 2.0 and OIDC federation configured per organization: metadata URL or manual endpoints, certificate, attribute mapping to account fields.
• Just-in-time account creation on first successful login, with a default org role set by the administrator.
• Optional attribute-to-role and attribute-to-group mapping, so an identity-provider group can drive GeoLibre group membership rather than being maintained twice.
• An org setting for whether built-in accounts remain allowed alongside federated ones, including a break-glass administrator account that survives an identity-provider outage.

2. SCIM provisioning

SCIM 2.0 for user and group create/update/deactivate, so joiners and leavers are handled by the identity provider. Deactivation must immediately invalidate active sessions and tokens, not merely prevent the next login.

3. Policy controls

For built-in accounts: password complexity and rotation, lockout after repeated failures. For all accounts: idle and absolute session timeouts, re-authentication before administrative actions, and an optional IP allowlist for administrative access specifically — an allowlist over ordinary use tends to break field work, which is a real GeoLibre use case.

4. Self-hosted deployments

The web container's HTTP Basic Auth is a single shared credential and is documented as such. Self-hosters who need real accounts should be able to front the container with their own identity-aware proxy and have GeoLibre consume the forwarded identity via trusted headers, with a strict allowlist of which upstream may set them. Document this path rather than reimplementing an identity provider in nginx.

Scope notes

• Depends on organizations and on OAuth sign-in. Filing it now to fix the shape of the target, not to schedule it.
• Almost entirely share.geolibre.app work plus a documented reverse-proxy contract for self-hosters. The app's own change is small: it consumes a session, and does not care how it was established.
• Do not build a bespoke MFA implementation if federation covers the requirement for the organizations that ask for it.

Effort

Wishlist, and the largest item in the umbrella.

---

Part of #1665 (access control umbrella).