Skip to content

Authentication and authorization

Authentication

PostGIS Service does not present or process a login form. Central creates sessions, and this service validates the acugis_session cookie by hashing its raw value with SHA-256 and querying an unexpired dashboard_sessions row joined to an enabled dashboard_users row.

The shared auth library can fall back to Authorization: Bearer ..., but the PostGIS auth-store provider is not configured with a personal-access-token store. Therefore bearer authentication is unsupported by the current service wiring, even though the sibling CLI supports Central PAT login. Use the Central session cookie for this service.

Unauthenticated non-HTML requests receive 401 authentication required. Browser-like HTML requests receive 303 to Central login with a next parameter. Authentication store failures return 503.

The auth DSN precedence is:

  1. POSTGIS_AUTH_DATABASE_URL
  2. CENTRAL_DATABASE_URL
  3. DATABASE_URL

The auth database must already contain the Central tables named in Database. This service does not create them.

Authorization

At startup, shared auth ensures catalog resources for all known platform services. Newly inserted resources receive an admin grant for the Administrators group if that group exists. PostGIS access checks use:

  • resource type: service
  • resource key: postgis_service
  • permissions: view, edit, admin

Users with is_admin=true or membership in Administrators bypass service permission lookup. For other users, admin satisfies all checks and edit also satisfies view. The shared permission check adds Public to a user's groups.

Route permission mapping

Request Required permission
GET/HEAD generally view
Non-GET generally edit
Non-GET connection operations admin
Non-GET access-rule/settings/database-access/database routes admin
Non-GET PostgreSQL user/group routes admin
POST jobs routes admin
Any terminal API path admin

Because matching is implemented with path substring tests, concrete behavior follows request paths rather than per-route annotations. All WebSocket endpoints also call an explicit service-admin check.

Development bypass

POSTGIS_SKIP_AUTH=1 or true injects user ID 1, username dev, admin status, and Administrators membership. It bypasses both authentication and authorization. The source has no safeguard preventing this in production; never set it on an exposed service.

Credential storage and transport

  • Registered PostgreSQL admin passwords are omitted from connection JSON responses.
  • With POSTGIS_SECRETS_KEY, values use AES-256-GCM with a random nonce and are stored as enc:<base64>.
  • Without the key, new values use plain:<password>. Legacy unprefixed values are also treated as plaintext.
  • Rotating the key is not implemented; values encrypted with an old key cannot be read after replacement unless re-encrypted externally.
  • Database subprocesses receive passwords through PGPASSWORD; GDAL receives the password inside its PostgreSQL datasource argument.
  • The Go listener serves plain HTTP. TLS termination is expected externally; the supplied Apache example provides the evidence for that architecture.

WebSocket protections

WebSocket upgrades require admin permission. If an Origin is supplied, its host must match X-Forwarded-Host (preferred) or the request host, with limited port normalization. Missing Origin is accepted. Session idle timeout is 30 minutes and maximum lifetime is eight hours.

Security boundaries not present

The source does not implement CSRF tokens, CORS headers, rate limiting, request-body limits except the 512 MiB upload cap, proxy trust restrictions, MFA, service-local PAT validation, or an audit database. Terminal audit records are standard process log lines.