The repository contains the extracted access seed implementation under src/govoplan_access/backend. Session, API-key, and password helper services, interactive auth routes, and administration routers are owned here. Access still exports govoplan_access.auth for compatibility, but sibling modules should import the core govoplan_core.auth facade so auth can become a provider-neutral capability. Modules must not import the backend dependency module directly. Access-side admin service helpers remain here for users, groups, roles, system accounts, sessions, API keys, tenant access enforcement, admin/audit lookup capabilities, tenant owner provisioning, and governance-template materialization into access-owned groups and roles. The module also enforces narrowly declared managed RoleTemplate.default_authenticated baselines. Their explicit permissions are derived from the active manifest set for every authenticated tenant member, without writing assignments during an authorization read. The optional role row is a non-assignable administration projection, not the source of the automatic grant. Domain permissions and resource policy remain separate checks. Governance-template metadata CRUD lives in govoplan-admin. The transitional administration WebUI route shell and access-owned panels live under webui/src as @govoplan/access-webui. Generic system administration panels are contributed by @govoplan/admin-webui through core's admin.sections UI capability. Live access ORM models are defined here with access_* table names. Access stores current scope identifiers in tenant_id columns but does not hard-depend on the tenancy module package. Tenancy-specific tenant administration and tenant resolver behavior live in govoplan-tenancy; governance templates in govoplan-admin, audit logs in govoplan-audit, and system settings in govoplan-core. The current access boundary is documented in:

/mnt/DATA/git/govoplan-core/docs/ACCESS_RBAC_MODEL.md
/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md
docs/ACCESS_MODULE_BOUNDARY.md
docs/IDENTITY_ACCOUNT_FUNCTION_MODEL.md
docs/OPENDESK_IDENTITY_BOUNDARY.md

Initial Ownership

This module will own:

accounts and login identity
authentication routes and session lifecycle
API keys
legacy administration route contribution during the transition
tenant-local users
identity-to-account projection for explainable access decisions
organization-bound functions and function assignments
explicit delegation and acting-in-place facts
groups and memberships
roles and role assignments
principal resolution
permission evaluation
access administration backend routes
access administration WebUI route contributions
compatibility FastAPI auth dependency API at govoplan_access.auth
provider-facing auth facade consumed by sibling modules at govoplan_core.auth
access administration, tenant provisioning, and governance materializer capabilities
access-owned migrations

The governance-template routes under /admin/system/governance-templates are contributed by govoplan-admin; access must not register those routes.

govoplan-access treats govoplan-tenancy as optional. Access can run in the single-scope compatibility mode used by the core/access baseline, and tenancy adds tenant administration plus tenant resolver behavior when installed.

Principal Context

The stable principal DTO is govoplan_core.core.access.PrincipalRef. Access resolves sessions, API keys, and future service accounts into that DTO and serializes it as principal in auth API responses. Feature modules should use that DTO, primitive IDs, or the core govoplan_core.auth dependency facade instead of importing access ORM models or backend dependency internals.

The detailed module boundary and serialization fields are documented in docs/ACCESS_MODULE_BOUNDARY.md.

For scheduled and event-driven work, Access provides auth.automationPrincipalProvider. Automation records store only an owner account/membership reference and an explicit least-privilege scope grant, not a session or API token. At delivery time Access rebuilds the principal from current roles, groups, functions, and delegations and intersects that authorization with the stored grant. Missing, inactive, moved, or under-authorized owners fail closed before module work starts.

WebUI Package

The repository root and webui/ directory both expose the package @govoplan/access-webui. The package contributes the /admin route and admin nav item through core's module WebUI contract. The route shell consumes module-owned admin.sections contributions from installed platform modules and continues to render access-owned tenant/user/group/role panels locally. Core supplies shared admin components, route rendering, and icon resolution.

The kernel remains responsible for module discovery, route aggregation, database/session lifecycle, migration orchestration, capability registry, and stable contracts.

Gitea Workflow

This repository uses the shared GovOPlaN Gitea issue workflow. Issue templates are installed under .gitea/, and the shared label taxonomy is copied to docs/gitea-labels.json.

From the core checkout, labels can be synced once a local GITEA_TOKEN is available:

cd /mnt/DATA/git/govoplan-core
/mnt/DATA/git/govoplan/tools/gitea/gitea-sync-labels.py --root /mnt/DATA/git/govoplan-access --apply

Development Install

From the core checkout:

cd /mnt/DATA/git/govoplan-core
./.venv/bin/python -m pip install -e ../govoplan-access

Interactive password login is throttled by normalized global login identity and by the directly connected client address. The deployment defaults are 10 identity failures and 100 client failures in a 15-minute window. Counters use REDIS_URL when Redis is reachable, allowing all API workers to share the same limits. Local development and Redis outages fall back automatically to a bounded, process-local counter; authentication remains available, but limits then apply per API process.

The deployment settings are AUTH_LOGIN_THROTTLE_ENABLED, AUTH_LOGIN_THROTTLE_IDENTITY_LIMIT, AUTH_LOGIN_THROTTLE_CLIENT_LIMIT, AUTH_LOGIN_THROTTLE_WINDOW_SECONDS, and AUTH_LOGIN_THROTTLE_REDIS_RETRY_SECONDS. Client-supplied forwarding headers are not trusted for throttling. A reverse proxy should pass the real peer address only through the platform's separately configured trusted-proxy boundary.

README.md

GovOPlaN Access

Initial Ownership

Principal Context

WebUI Package

Gitea Workflow

Development Install

Login Throttling