feat(invitations): provision guests directly into the directory (ldap backend)

[dj4oC]

Problem

The invitations service (POST /graph/v1.0/invitations) provisions invited guests in
an external Keycloak IdP. Such a guest is not immediately present in the directory
oCIS reads for share-recipient resolution (the documented "provisioning delay" in
services/invitations/README.md), so it cannot be used as a share recipient until it
has been synced/logged in. The graph invite handler validates the recipient via
identityCache.GetUser (services/graph/.../api_driveitem_permissions.go) and rejects
unknown ids, so "invite an external by email, then share with them" cannot work right
after the invitation.

Solution

Add a second invitation backend that provisions the guest directly into the oCIS
identity backend (LDAP), selected with a new INVITATIONS_BACKEND env var:

• keycloak (default) — unchanged behaviour.
• ldap — creates the guest (userType=Guest) in the same directory oCIS reads, via
  the existing identity.LDAP backend. The guest is therefore immediately resolvable
  through the Graph API and usable as a share recipient. Requires
  OCIS_LDAP_SERVER_WRITE_ENABLED=true.

The invitation response also returns the created user as invitedUser (id, email,
userType), which a client needs to then share with the guest.

Changes

• services/invitations/pkg/backends/idm/ — new backend provisioning guests via a
  DirectoryProvisioner (satisfied by *identity.LDAP); unit-tested.
• services/invitations/pkg/service/v0/service.go — INVITATIONS_BACKEND selector;
  the ldap backend reuses the graph LDAP schema defaults and only overrides the
  connection/write settings from the invitations config.
• services/invitations/pkg/config — INVITATIONS_BACKEND + INVITATIONS_LDAP_*.
• ocis/pkg/init — ocis init now provisions the invitations LDAP bind password with
  the same idm service password the graph identity backend uses, so the ldap backend
  works out of the box.
• deployments/examples/ocis_full — enables LDAP write + the ldap invitation backend
  and runs the invitations service, so an invited guest is shareable out of the box.

Testing

• go test ./services/invitations/... -race — passes (new idm backend unit tests +
  existing keycloak tests).
• End-to-end against a running oCIS (single binary, INVITATIONS_BACKEND=ldap,
  OCIS_LDAP_SERVER_WRITE_ENABLED=true):
  1. POST /graph/v1.0/invitations → 201, invitedUser returned with userType=Guest.
  2. GET /graph/v1.0/users/{id} → 200 immediately (resolvable).
  3. graph invite of that guest onto a folder → 200 (share succeeds).
     Verified relying solely on the ocis init-provisioned bind password (no manual secret).

Notes / limitations

• The ldap backend provisions the guest but does not send a credential-setup email
  (that remains a Keycloak feature). It fits IDM-managed deployments; for a guest
  login/email flow, combine with Keycloak.
• Prototype: the ldap backend reuses services/graph/pkg/identity + its config
  defaults. A cleaner long-term home would be a shared identity package.

Risk

Low. INVITATIONS_BACKEND defaults to keycloak (unchanged behaviour); the new path is
opt-in. The ocis_full change is confined to the example deployment.

🤖 Generated with Claude Code

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[dj4oC]

Out of scope: add LDAP to the ocis_full example