Use core auth and scope contracts
This commit is contained in:
29
README.md
29
README.md
@@ -6,10 +6,11 @@ administration.
|
||||
|
||||
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. The public
|
||||
FastAPI request dependency API is exported from `govoplan_access.auth`; modules
|
||||
must not import the backend dependency module directly. Access-side admin
|
||||
service helpers remain
|
||||
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
|
||||
@@ -18,10 +19,12 @@ 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; tenant records 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:
|
||||
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`
|
||||
@@ -47,7 +50,8 @@ This module will own:
|
||||
- permission evaluation
|
||||
- access administration backend routes
|
||||
- access administration WebUI route contributions
|
||||
- published FastAPI auth dependency API at `govoplan_access.auth`
|
||||
- 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
|
||||
@@ -55,15 +59,16 @@ This module will own:
|
||||
The governance-template routes under `/admin/system/governance-templates` are
|
||||
contributed by `govoplan-admin`; access must not register those routes.
|
||||
|
||||
`govoplan-access` depends on `govoplan-tenancy`; the registry loads tenancy
|
||||
before access for authenticated platform composition.
|
||||
`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 published `govoplan_access.auth` dependency API
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user