Identity First: LDAP Employee Sync and Enterprise-Grade RBAC

This is part 3 of the Musaned series. Part 2 covered the Laravel + Filament stack decision.

The first feature I built for Musaned wasn't a feature anyone asked for. Before the first business screen existed, the platform needed to answer two questions correctly, every time: who are you, and what are you allowed to do. Get those wrong in an enterprise and nothing else you build matters.

No manual accounts, ever

The fastest way to lose control of an internal system is to let it grow its own user database. Someone creates an account for a colleague, that colleague changes departments, nobody remembers the account exists, and two years later an auditor asks why a person who left the company can still see voucher data.

So Musaned doesn't have manual account creation. Employees come from one source of truth: the corporate directory, over LDAP. A scheduled sync job keeps the local user table aligned with the directory — new employees appear, departed employees are deactivated, and the platform never has to be told twice. The sync is deliberately one-directional: Musaned reads from the directory; it never writes back. Identity belongs to the organization, not to my application.

Was LDAP integration glamorous work? Not remotely. But it removed an entire category of security risk and administrative overhead before either could take root — and it meant that from day one, logging into Musaned felt like logging into something official.

RBAC as the product's skeleton

With identity solved, the second layer is authorization. Musaned's RBAC is strict in a specific sense: every module, every action, every record type is gated by permission, and the default answer is no. A user with no roles sees an almost empty application. Roles map to business functions — not to org-chart titles, which change too often, and not to individuals, which doesn't scale past ten users.

Three rules kept the model sane as the platform grew:

• Permissions are named after actions, not screens. "query vouchers" and "export vouchers" are separate permissions, because seeing data and extracting data are different levels of trust.

• Roles are composed, never customized per person. If someone needs an unusual combination, that's a new role with a name and an owner — which means it can be reviewed and revoked as a unit.

• Sensitive actions assume an audience. Anything touching customer or voucher data is logged with who did it and when. The log exists so that the answer to "who saw this?" is a query, not an investigation.

Why this was worth doing before anything else

Strict RBAC felt like overengineering when the platform had five users. It stopped feeling that way the day upper management started using Musaned (a story coming later in this series — the BPM tool went all the way to the CEO's office). When executives rely on a system, "who can see what" becomes a question you must answer instantly and confidently. We could, because the skeleton was there from the start.

The lesson I'd hand any engineer building an internal platform: identity and authorization are not features you add when the system matters. They're how the system comes to matter.

Next in the series: the Oracle chapter — Instant Client pain, oci8, and why SQL*Plus became our bulk-processing workhorse for 2M+ records.