hieunguyen30 opened a new pull request, #517:
URL: https://github.com/apache/airavata-custos/pull/517
## Summary
Adds a direct-to-LDAP counterpart to the COmanage Identity-Provisioner
(#487) for sites that don't front their directory with a COmanage
Registry. Mirrors COmanage's shape end-to-end: same package layout
(`pkg/ldap/loader.go` + `internal/{client,operations,subscribers}`),
same event subscription (`ComputeClusterUserCreateEvent`), same audit
and tracing surface, same idempotency contract with cluster filtering.
## What the connector does
For each accepted `ComputeClusterUserCreateEvent` the orchestrator:
1. Validates that the `LocalUsername` is POSIX-safe (`[a-z_][a-z0-9_-]*`,
≤32 chars) — as a side-effect this rejects every RFC 4514 DN
metacharacter so the RDN can be concatenated safely.
2. Looks up a cached `uidNumber` in
`user_identities(source="ldap:<clusterID>")`.
The source string is scoped per cluster so a deployment servicing
multiple clusters keeps each cluster's uids independent.
3. If no cache, looks up an existing entry in LDAP (out-of-band or a
prior run that failed to cache) and adopts its uid.
4. Otherwise, allocates a fresh uid via `client.AllocateAndAddPosixAccount`
which holds a mutex across the LDAP scan and the subsequent Add.
Retries on cross-process constraint violation with an ever-higher
floor.
5. Emits `LDAPAccountCreated` on Add, `LDAPAccountUpdated` on Modify.
6. When `LDAP_GROUP_BASE_DN` is set, ensures a matching `posixGroup`
entry with `gidNumber = uidNumber` exists. Concurrent creation is
tolerated (`EntryAlreadyExists` treated as success).
All success events (`LDAPAccountCreated`, `LDAPAccountUpdated`,
`LDAPGroupCreated`) are registered as terminal audit-trace markers in
the loader's `init()`, so the audit UI closes provisioning runs rather
than leaving them at `in_progress` — same pattern as COmanage and AMIE.
## Known limitation of the naive allocator
The `max(uidNumber) + 1` approach is intentionally the v1 shape. Two
correctness gaps that a durable allocator would close:
1. A deleted LDAP entry's uidNumber can be reused, which risks a new
user inheriting file ownership stamped with the old numeric uid on
the cluster.
2. Cross-process races rely on the LDAP server having a `uidNumber`
uniqueness constraint configured.
The `user_identities` cache mitigates the first gap for users Custos
still knows about (re-provisioning gets the prior uid back via the
cache-hit path). The mutex plus retry-with-higher-floor mitigates
in-process races and cross-process ones on well-configured servers.
The right long-term fix is either a persistent monotonic counter in
this connector's own table or delegating uid assignment to a
server-side plugin (389 DS DNA / FreeIPA). Which of those the
connector should target is a design question I'd like to discuss
before opening the follow-up PR.
## Test plan
- [x] `go build ./...` — clean across the whole repo
- [x] `go test ./connectors/LDAP/Provisioner/...` — 24 unit tests
passing, no live LDAP/DB
- [x] `go test ./...` — full repo clean, no upstream breakage
- [ ] Manual smoke test against a real OpenLDAP container —
recommended before merge; command in `README.md` under "Local
development"
## Files
- `connectors/LDAP/Provisioner/pkg/ldap/loader.go` — entry point,
env-var and YAML config, skip-with-log if config absent
- `connectors/LDAP/Provisioner/internal/client/` — LDAP protocol
wrapper (Find, Add, Modify, atomic AllocateAndAdd, allocator scan,
group Find/Add)
- `connectors/LDAP/Provisioner/internal/operations/` — orchestrator
(adopts, allocates, retries), primary-group provisioning
- `connectors/LDAP/Provisioner/internal/subscribers/` — event handler
with cluster filtering
- `connectors/LDAP/Provisioner/{README.md, config.example.yaml}`
- `internal/connectors/loader.go` — one-line registration
- `go.mod` — adds `github.com/go-ldap/ldap/v3`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
