hieunguyen30 opened a new pull request, #518:
URL: https://github.com/apache/airavata-custos/pull/518
## 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 (same layout, same event
subscription, same audit and tracing surface, same idempotency
contract with cluster filtering), adapted for the fact that raw LDAP
has no upstream identifier-assignment plugin the way COmanage
Registry does.
## UID allocation
The design principle behind the COmanage connector is that the
identity registry owns the uidNumber and Custos reads and caches. On
the direct-LDAP path there is no such upstream registry, so the
connector takes on that responsibility: a persistent monotonic
counter lives in the connector's own `ldap_uid_sequence` table (one
row per cluster, atomic `LAST_INSERT_ID(next_uid + 1)` under InnoDB
row locking). Same connector-owned-DB pattern AMIE already uses in
this repo. The counter is seeded once at startup from
`max(LDAP scan, MinUID)` so a fresh install picks up above any
entries provisioned out-of-band; after that it never scans LDAP for
allocation.
Compared to a naive `max(uidNumber) + 1` scan this gives:
- No uid reuse after entry deletion (counter is monotonic across
restarts).
- No dependency on the target LDAP having a `uidNumber` uniqueness
constraint configured — InnoDB serialises callers itself.
- O(1) allocation cost rather than O(N) scan per new user.
## What the connector does
For each accepted `ComputeClusterUserCreateEvent` the orchestrator
validates the local username, resolves the Custos user, either reads
the cached uidNumber from `user_identities(source="ldap:<clusterID>")`
or adopts an existing LDAP entry, or (for new users) pulls a fresh
uid from the counter and writes a `posixAccount` entry. When
`LDAP_GROUP_BASE_DN` is set it also writes a matching `posixGroup`
with `gidNumber = uidNumber`. Terminal audit-trace markers on all
success events so the audit UI closes provisioning runs.
## Test plan
- [x] `go build ./...` — clean
- [x] `go test ./connectors/LDAP/Provisioner/...` — 38 unit tests
passing, no live LDAP/DB
- [x] `go test ./...` — full repo clean
- [x] `go test -tags integration
./connectors/LDAP/Provisioner/internal/store/...`
passes against a live MariaDB (5 tests covering seed
idempotency, monotonicity, concurrent-allocator distinctness,
per-cluster isolation, and the "Allocate without Seed" error
path)
- [ ] Manual smoke test against a real OpenLDAP container — command
in `README.md` under "Local development"
## Alternative allocator strategies considered
Delegating uid assignment to a server-side plugin (389 DS DNA /
FreeIPA) would be closer to COmanage's "delegate upstream" shape and
would let Custos own zero schema for this connector. I did not go
that direction because it restricts deployment to servers with that
specific plugin — plain OpenLDAP has no first-party equivalent. If
the intended direct-LDAP target is FreeIPA specifically, the
`client.AllocateAndAddPosixAccount` entry point could be swapped for
a delegate-to-DNA implementation without changing the orchestrator
or the caching model. Happy to iterate in that direction if that
fits the deployment target better than a Custos-side counter.
--
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]
