Metadata-Version: 2.4
Name: govoplan-idm
Version: 0.1.18
Summary: GovOPlaN identity management bridge module.
Author: GovOPlaN
Requires-Python: >=3.12
Description-Content-Type: text/markdown
Requires-Dist: govoplan-core>=0.1.18
Requires-Dist: govoplan-identity>=0.1.18
Requires-Dist: govoplan-organizations>=0.1.18

# 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
- typed business groups and effective-dated identity relationship links
- 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}`
- `GET|POST /api/v1/idm/typed-groups`
- `PATCH /api/v1/idm/typed-groups/{group_id}`
- `GET|POST /api/v1/idm/relationships`
- `PATCH /api/v1/idm/relationships/{relationship_id}`
- `POST /api/v1/idm/relationships/{relationship_id}/revoke`
- `GET /api/v1/idm/typed-groups/{group_id}/memberships`

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.

Its interface archetypes, consequence classes, contextual-help contract, and
accessibility evidence are recorded in
[`docs/INTERFACE_PATTERN_MIGRATION.md`](docs/INTERFACE_PATTERN_MIGRATION.md).

## 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.

Function requests and holder/authority initiated grants require a governed
change record before the effective assignment is created. The target journeys,
grant profiles, state model, and module boundaries are documented in
[Function assignment request and grant workflows](docs/FUNCTION_ASSIGNMENT_WORKFLOWS.md).

Assignments with a future `valid_until` are resolved as ineffective immediately
after that boundary. When Celery beat and an IDM-capable worker are running, the
shared `govoplan.idm.expire_assignments` task also emits the corresponding
`idm.function_assignment.expired.v1` event. IDM records the event marker in the
same database transaction, making repeated sweeps idempotent.

Typed group and relationship behavior, including effective-time resolution and
the provider-neutral capability consumed by Distribution Lists, is documented
in [Typed groups and effective-dated relationships](docs/TYPED_RELATIONSHIPS.md).

## 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.
