4.1 KiB
OpenDesk Identity Integration Boundary
OpenDesk-style identity integrations should terminate in govoplan-access as
canonical accounts, tenant memberships, groups, roles, sessions, and principal
claims. Provider protocol details may live in access subpackages or dedicated
connector modules, but other GovOPlaN modules must consume identity through
access capabilities, typed DTOs, events, and published route dependencies.
Boundary Decision
govoplan-access owns the identity projection and authorization effects:
- external identity links for accounts and memberships
- authentication callback/session issuance for federated login
- claim, group, and role mapping into access-owned roles and memberships
- SCIM-style provisioning effects for accounts, users, groups, and group membership
- account suspension/deactivation effects that influence sessions and API keys
- audit-relevant identity events emitted through kernel event/audit contracts
Connector packages may own provider-specific transport and schema logic:
- LDAP and Active Directory bind/search/sync adapters
- OIDC and SAML provider metadata, callback protocol handling, and claim normalization
- SCIM client/server protocol specifics
- Open-Xchange identity lookup or provisioning clients
Those connectors should call access capabilities or access-owned service APIs instead of writing access tables directly.
Integration Types
LDAP And Active Directory
LDAP/AD adapters may authenticate credentials, search directory entries, and sync group membership. Access owns the resulting account, membership, group, and role mapping. Directory groups should map to access groups or role assignments through explicit mapping rules; they should not grant feature module permissions directly.
OIDC And SAML
OIDC/SAML adapters may handle provider metadata, assertions, tokens, and claim
normalization. Access owns external subject linking, session creation, tenant
selection, first-login behavior, and claim-to-role/group mapping. Feature
modules should see only PrincipalRef, UserRef, scopes, group IDs, and
tenant context.
SCIM Provisioning
SCIM provisioning belongs at the access boundary because it mutates accounts, memberships, groups, and deactivation state. Tenant resolution remains a kernel or tenancy capability concern. SCIM must not provision mailboxes, calendars, campaign ownership, or file spaces directly; those modules may react to access-published identity events when needed.
Open-Xchange Touchpoints
Open-Xchange identity/contact integration should split identity from collaboration data:
- Access owns external account IDs, email/display-name identity fields, membership state, group references, and auth/session effects.
- Mail, calendar, contacts, or connector modules own mailboxes, address books, calendar resources, contact folders, and provider-specific collaboration objects.
Access may publish identity-change events and stable DTOs that those modules consume, but it should not import their internals or own their provider data.
Non-Goals
Access does not own:
- campaign ACLs, campaign ownership, delivery policy, or recipient contacts
- file storage permissions beyond principal/group identity references
- mail profile credentials, mailbox state, or reusable mail-server profiles
- calendar availability, appointments, rooms, or contact address books
- provider-specific UI panels for non-identity configuration
Those belong to their owning modules and should integrate through capabilities or events.
Implementation Shape
Provider integration should be added in small slices:
- Define an access-owned external identity link model and DTO surface.
- Add provider adapter contracts that normalize external subjects, groups, claims, and deactivation signals.
- Route OIDC/SAML login callbacks through access so sessions are issued by the access session service.
- Route LDAP/AD/SCIM provisioning through access administration services and tenant provisioning capabilities.
- Publish identity-change events for optional mail/calendar/contact/file reactions without adding module-to-module imports.