98 lines
4.1 KiB
Markdown
98 lines
4.1 KiB
Markdown
# 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:
|
|
|
|
1. Define an access-owned external identity link model and DTO surface.
|
|
2. Add provider adapter contracts that normalize external subjects, groups,
|
|
claims, and deactivation signals.
|
|
3. Route OIDC/SAML login callbacks through access so sessions are issued by
|
|
the access session service.
|
|
4. Route LDAP/AD/SCIM provisioning through access administration services and
|
|
tenant provisioning capabilities.
|
|
5. Publish identity-change events for optional mail/calendar/contact/file
|
|
reactions without adding module-to-module imports.
|