Eloquent Ldap Laravel Package

Product Decisions This Supports

• Enterprise onboarding strategy: the package enables a hybrid auth model — employees authenticate against corporate AD/LDAP, while contractors, partners, and service accounts live in the app's own users table. This directly supports a decision to sell into enterprises without forcing a full IdP migration as a launch prerequisite.
• Build vs. buy vs. borrow (the real decision): the functionality is narrow — a user provider/guard that attempts Auth::attempt() locally, then falls back to a bind against the configured directory. Expect a competent Laravel engineer to reproduce this in 1–3 days. The decision is therefore not "adopt this package" but "do we own ~150 lines of auth code, or take a dependency?"
• Roadmap sequencing for SSO: this is a pre-SAML/OIDC stopgap. It informs whether SSO lands in the current cycle (buy a real IdP integration) or whether a lightweight AD bind defers that investment for a quarter or two.
• Migration/cutover use case: useful when a customer is moving off AD but not yet off it — local DB is authoritative, directory is the fallback for un-migrated accounts. Also supports the reverse during a phased rollout.
• Compliance/security review scope: adopting it makes "how do we authenticate against customer-managed directories?" an architecture decision that needs to be documented for security questionnaires and SOC 2 evidence.

Recommendation: do not adopt as a dependency. The GPL-3.0 license is a likely blocker for any commercial or closed-source product (copyleft; Laravel's ecosystem norm is MIT), and the maintenance signals are weak — 20 stars, zero dependents, single maintainer, low opportunity score. Re-implement the fallback logic internally (clean IP, MIT-compatible) or adopt an actively maintained MIT-licensed alternative, and treat this repo as a reference implementation rather than a dependency.

When to Consider This Package

Consider it (as reference code, or a dependency only in a GPL-compatible internal tool):

• The product is deployed internally to a single organization that already runs AD/LDAP, so GPL obligations are moot and there is no redistribution.
• You need hybrid local + directory auth this sprint and cannot wait for a proper IdP integration.
• The requirement is genuinely just username/password bind — no group-to-role mapping, no MFA, no directory sync, no password-change flow.
• You have the appetite to fork and maintain it, because you should assume the upstream will go quiet.
• The directory is reachable over a private network / VPN with predictable latency.

Look elsewhere (strongly) when:

• You ship commercially or on-prem to customers. GPL-3.0 is the wrong license for a proprietary distribution; legal review will likely stop this.
• You need authorization, not just authentication. No role/group mapping means you still need to build entitlements — the bulk of the work remains.
• You need MFA, conditional access, or modern SSO. This is credential bind, not federation. For SAML/OIDC use a dedicated IdP integration.
• You need directory write-back (password reset, attribute sync, provisioning). Look at a maintained LDAP integration library instead.
• Latency or availability matters. A fallback chain means a slow or unreachable directory can add timeout delay to every login attempt; you need circuit-breaking and cached group data, which this package does not appear to provide.
• You need audit-grade logging of which store authenticated a given user (required for access reviews).

Security questions to answer before any adoption — these are unresolved by the package and are the PM's real risk:

• Local-first fallback makes the app's own credential store the first thing an attacker probes. Is rate limiting and lockout applied across both paths, or can a failed local attempt leak timing/behavior differences that reveal valid local accounts?
• Does a user who exists in both stores get silently authenticated by the weaker one? Password drift between AD and local DB is a real operational hazard.
• Is a stale local account a backdoor once an employee is offboarded in AD? Deactivation in the directory must invalidate the local path — this must be an explicit product rule.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small open-source connector that lets users log in with their existing corporate Windows/AD credentials instead of a new password. It would let us land enterprise accounts faster and reduce onboarding friction for employees whose company mandates a directory. However, it's a stopgap, not a platform: it's a 20-star community project maintained by one person, under a GPL-3.0 license that is incompatible with our commercial distribution model, and it solves only half the problem — login, not permissions. My recommendation is not to take it as a dependency. We can own equivalent logic in a few engineering days with no license encumbrance, and pair it with our existing auth so we retain full control. It is not a strategic investment; it is a checkbox that helps us close deals with on-prem enterprises, and we should price the effort accordingly.

To engineering (short): The behavior is: try the local guard, on failure attempt an LDAP/AD bind, then materialize/sync the user. Treat it as a design reference, not a vendor. We'll implement the fallback in our own user provider so we control (a) lockout and rate limiting across both paths, (b) a guarantee that directory-side deactivation invalidates local access, (c) explicit audit logging of which store authenticated the request, and (d) connection timeouts with circuit-breaking so an unreachable domain controller doesn't stall logins. Estimate 1–3 days for the core path, plus test coverage and a fake LDAP server for CI. If we later need group-to-role mapping, we evaluate a maintained LDAP library rather than extending this.

To sales/customer success: If a prospect asks "does it work with our Active Directory?", the answer is "yes, in a limited way — username/password against your domain controller." It does not get us SSO, MFA, or automatic deprovisioning. Don't let it be promised as enterprise SSO.

Bottom line for the roadmap: log it as a low-priority, low-effort enterprise-enablement item — not a dependency to adopt, but a pattern to implement internally when an AD-based deal makes it revenue-relevant. Revisit only if two or more signed customers require it.