Files
govoplan-idm/README.md
2026-07-11 16:49:02 +02:00

143 lines
6.0 KiB
Markdown

# GovOPlaN IDM
<!-- govoplan-repository-type:start -->
**Repository type:** module (platform).
<!-- govoplan-repository-type:end -->
`govoplan-idm` is the planned integration module for external identity
management systems. It does not own GovOPlaN's internal identity, organization,
account, role, or tenant tables; those remain with `govoplan-identity`,
`govoplan-organizations`, `govoplan-access`, and `govoplan-tenancy`.
The module's purpose is to connect GovOPlaN to upstream identity providers and
directory-management processes without making the platform depend on a single
vendor or protocol.
## Boundary
`govoplan-idm` should own:
- inbound synchronization from external identity-management systems
- identity lifecycle import, update, disable, and reconciliation jobs
- identity-to-organization-function assignment links inside GovOPlaN
- bridge views that combine identity and organization facts, such as identity
candidates for organization function assignments
- mapping external identities, accounts, groups, organizational units,
functions, and attributes to GovOPlaN identity, organization, access, and
tenancy DTOs
- provider-specific connectors for LDAP/AD, SCIM, OIDC profile claims, and
public-sector directory services once those targets are selected
- dry-run previews, conflict reports, audit events, and rollback metadata for
identity synchronization
It must not own:
- password authentication, sessions, API keys, or CSRF behavior
- GovOPlaN RBAC permission evaluation
- tenant lifecycle storage
- application-specific authorization rules
- portal citizen identities unless that flow is explicitly delegated to an
identity-trust or portal module
## Kernel Contract
The module should integrate through kernel capabilities and access-owned public
APIs:
- read/write identities through `govoplan-identity` capability contracts
- resolve organization units and functions through `govoplan-organizations`
- resolve tenants through `govoplan-tenancy`
- hand accepted role/right effects to `govoplan-access`
- emit synchronization and conflict events through the shared event contract
- write audit evidence through the audit sink capability
- expose admin routes through module route contributions
- contribute WebUI admin panels through module UI metadata
No feature module should import IDM internals directly. Feature modules should
ask access, tenancy, or future directory capabilities for normalized identity
facts.
`govoplan-idm` has hard module dependencies on `govoplan-identity` and
`govoplan-organizations`, because its core value is connecting those normalized
facts. Identity remains the owner of identities/accounts. Organizations remains
the owner of units/functions.
## Current Runtime API
The first runtime API exposes identity lookup and organization-function
assignment links:
- `GET /api/v1/idm/settings`
- `PATCH /api/v1/idm/settings`
- `GET /api/v1/idm/organization-identities`
- `GET /api/v1/idm/organization-function-assignments`
- `POST /api/v1/idm/organization-function-assignments`
- `PATCH /api/v1/idm/organization-function-assignments/{assignment_id}`
The candidate endpoint returns searchable identity/account candidates for IDM
assignment forms. Assignment writes validate the identity/account link through
`govoplan-identity` and the function/unit scope through
`govoplan-organizations`. These endpoints exist only when IDM is enabled, which
implies both identity and organizations are enabled through module dependency
planning.
The WebUI exposed by this repository is a normal module UI at `/idm`. It is the
editing surface for identity-to-organization-function assignment links.
## Migration And Permission Transition
The initial IDM migration creates new IDM-owned tables only. No data is migrated
from the legacy access/organization assignment tables.
Canonical permissions for assignment work are:
- `idm:organization_identity:read`
- `idm:organization_assignment:read`
- `idm:organization_assignment:write`
- `idm:settings:read`
- `idm:settings:write`
During the transition, `organizations:function:assign` remains accepted by IDM
assignment and identity-candidate endpoints as a compatibility scope. New role
templates and documentation should use the IDM scopes. Organizations remains the
owner of units and function definitions; IDM owns identity-to-function
assignment links.
`govoplan-access` can consume IDM assignments through the optional
`idm.directory` capability when IDM is installed. This is deliberately optional:
access still works without IDM, and IDM does not require access to store or edit
assignment links. If the audit module is enabled, IDM records assignment and
settings audit events; otherwise the assignment API remains usable without an
audit hard dependency.
An IDM assignment does not grant application permissions by itself. Access grants
role-derived permissions only when an explicit external function role mapping
connects the organization function ID to an assignable role. Those mappings are
managed through the access API at
`/api/v1/admin/external-function-role-mappings`.
Tenant IDM settings can require recorded change requests before assignment
creates or updates are applied. The change-control key is
`idm.organization_assignments`.
Delegated and acting-for assignments are source-specific:
- `delegated` requires a source assignment for the same function, and the
organization function must allow delegation.
- `acting_for` requires a source assignment for the same function, an
acting-for account on that source identity, and the organization function must
allow acting in place.
## First Milestone
The first useful milestone is a read-only synchronization preview:
1. Configure one external directory source.
2. Fetch users/groups/organizational units into a transient snapshot.
3. Map the snapshot to GovOPlaN accounts, users, groups, and tenant bindings.
4. Show creates, updates, disables, conflicts, and skipped records.
5. Emit audit evidence for the preview run.
Applying changes should come later, behind dry-run approval, conflict policy,
rollback metadata, and maintenance-mode safeguards.