Directory Bundle Laravel Package

Technical Evaluation

Architecture Fit

• LDAP/AD Integration: The bundle provides a Symfony wrapper for Active Directory (AD) access, which is a highly specialized use case for enterprise applications requiring user/group authentication, directory lookups, or LDAP-based workflows. It fits well in architectures where:
  • AD is the single source of truth for identity management.
  • Legacy systems or hybrid environments require LDAP bridging to modern PHP/Symfony apps.
  • Multi-domain AD forests need centralized directory access.
• Symfony Ecosystem: Designed for Symfony 2.x (likely incompatible with Symfony 5/6+ without refactoring). Assumes Symfony’s dependency injection (DI) and bundle architecture, which may require adjustments for non-Symfony PHP projects.
• Limited Abstraction: The bundle does not abstract LDAP operations beyond basic server configuration—developers must handle queries, filters, and responses manually (e.g., via ldap_search() under the hood). This increases coupling to LDAP-specific logic.

Integration Feasibility

• Symfony Projects: Low risk for existing Symfony 2.x apps. For Symfony 3/4/5/6, moderate risk due to potential API changes (e.g., YAML config → PHP config, event system updates).
• Non-Symfony PHP: High risk—requires wrapping the bundle in a standalone library or adapting its core logic (e.g., LDAP client) to a non-Symfony context.
• Modern Stacks: Conflicts likely with:
  • Symfony’s Flex/auto-wiring (bundle uses AppKernel registration).
  • PHP 8.x (last release in 2016; may lack type safety or deprecated function support).
  • PSR-15/HTTP Message standards (if async LDAP is needed).

Technical Risk

Key Questions

1. Why not use the native php-ldap extension directly?
   • Does the bundle add value beyond raw LDAP calls (e.g., caching, retry logic, AD-specific optimizations)?
   • Are there Symfony-specific integrations (e.g., security voters, firewalls) that justify the bundle?
2. AD Topology Complexity:
   • Will the app interact with multi-domain forests, read-only DCs, or global catalogs? The bundle’s simplicity may not handle these well.
3. Future-Proofing:
   • Is Cisco’s internal use case (implied by "Global VE") aligned with your needs? Avoid vendor-lock to Cisco-specific AD schemas.
4. Alternatives:
   • Evaluate adldap2/adldap2 (active, feature-rich) or [php-ldap + custom service layer**.
5. Compliance:
   • Does the bundle support LDAPS (secure LDAP)? Check if ldaps:// is configurable or if it defaults to ldap://.

Integration Approach

Stack Fit

• Symfony 2.x: Native fit—minimal changes required beyond config.
• Symfony 3/4/5/6:
  • Option 1: Fork the bundle, update to Symfony’s latest DI component, and replace YAML config with PHP (config/packages/).
  • Option 2: Extract LDAP logic into a standalone service (e.g., DirectoryClient) and use the bundle’s config as a template.
• Non-Symfony PHP:
  • Option 1: Use the bundle’s LDAP client class (CiscoSystems\DirectoryBundle\Service\DirectoryService) as a reference and rebuild functionality.
  • Option 2: Replace entirely with php-ldap + a lightweight service layer (e.g., using PSR-11 for DI).

Migration Path

1. Assessment Phase:
   • Audit current LDAP usage (e.g., user auth, group lookups, schema queries).
   • Compare feature parity with alternatives (e.g., adldap2).
2. Pilot Integration:
   • Start with a single AD server in config.yml (or equivalent).
   • Test critical paths (e.g., user authentication, group membership checks).
3. Gradual Rollout:
   • Replace direct LDAP calls with bundle services (e.g., inject DirectoryService).
   • Phase out old LDAP code incrementally.
4. Fallback Plan:
   • Maintain a direct php-ldap fallback for critical paths during transition.

Compatibility

Sequencing

1. Dependency Setup:
   • Add cisco-systems/directory-bundle:dev-master to composer.json.
   • Install php-ldap extension (pecl install ldap or via package manager).
2. Configuration:
   • Start with minimal config.yml (single server).
   • Gradually add repository, default_rdn, etc., as needed.
3. Service Integration:
   • Inject directory.main service (or custom alias) into controllers/services.
   • Example:

     use CiscoSystems\DirectoryBundle\Service\DirectoryService;
     
     class UserResolver {
         public function __construct(private DirectoryService $directory) {}
         public function findUser(string $username): ?array {
             return $this->directory->search('(sAMAccountName=' . $username . ')');
         }
     }
     

4. Testing:
   • Validate against edge cases (e.g., disconnected DCs, invalid credentials).
   • Test performance under load (LDAP can be a bottleneck).

Operational Impact

Maintenance

• Pros:
  • Centralized AD configuration (avoids hardcoded credentials in code).
  • Bundle structure may encapsulate LDAP complexity.
• Cons:
  • No active maintenance—bug fixes or security patches must come from your team.
  • Symfony-specific maintenance overhead if using in non-Symfony contexts.
• Recommendations:
  • Document internal patching process (e.g., GitHub fork strategy).
  • Schedule quarterly compatibility reviews with Symfony/PHP updates.

Support

• Limited Community:
  • Only 1 star, 0 dependents—expect no external support.
  • Cisco’s "Global VE" context suggests internal-only use; may lack enterprise AD expertise.
• Debugging:
  • Log LDAP errors explicitly (bundle may not surface them clearly).
  • Example debug config:

    cisco_systems_directory:
        debug: true
        log_level: debug
    

• Fallbacks:
  • Implement circuit breakers for LDAP failures (e.g., cache results, show degraded UI).

Scaling

• Horizontal Scaling:
  • LDAP connections are not connection-pooled by default—risk of connection exhaustion under high traffic.
  • Mitigation: Use a connection pool (e.g., ext-ldap’s ldap_connect() with persistent links or a library like rubix/ml).
• Performance:
  • No built-in caching—frequent AD queries may impact performance.
  • Mitigation: Add Redis/Memcached caching for static data (e.g., group memberships).
• Multi-Region:
  • Bundle supports multiple servers (primary/secondary), but no geo-routing logic.
  • Mitigation: Extend config to include region-aware server selection.

Failure Modes