Relay Greenlight Connector Campusonline Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Legacy Dependency: The bundle is tightly coupled to DCC (Digital COVID Certificate) infrastructure, which is deprecated since June 2023. This makes it non-functional for modern use cases unless the Austrian Government’s CampusOnline/LDAP integration is still required for a very specific, niche scenario (e.g., legacy compliance).
• Symfony/Laravel Compatibility:
  • Designed as a Symfony Bundle, not a Laravel package. While Laravel can technically use Symfony bundles via symfony/flex, this introduces unnecessary complexity and maintenance overhead.
  • If Laravel is the target, a custom wrapper or adapter would be needed, increasing technical debt.
• Functional Scope:
  • Primarily fetches images from CampusOnline and retrieves co-obfuscated-c-ident from LDAP.
  • No clear business value unless tied to a specific Austrian Government digital identity system (e.g., legacy Green Pass verification).
  • No modern authentication/authorization standards (e.g., OAuth2, OpenID Connect).

Integration Feasibility

• LDAP Dependency:
  • Requires an active LDAP server with the correct schema (co-obfuscated-c-ident).
  • No built-in fallback or mocking for testing without LDAP.
• CampusOnline API Dependency:
  • No documentation on API endpoints, rate limits, or authentication.
  • No error handling for API failures (e.g., CampusOnline downtime).
• Symfony-Specific Components:
  • Uses Symfony’s Dependency Injection (DI) container, EventDispatcher, and Bundle architecture.
  • Laravel’s Service Container and Event System would require significant refactoring to integrate.

Technical Risk

Key Questions

1. Is CampusOnline/LDAP still a business requirement?
   • If no, this package is obsolete and should be replaced or removed.
   • If yes, is the Austrian Government still supporting this integration?
2. Can we replace this with a modern alternative?
   • Example: Use Laravel’s HTTP client (Guzzle) + LDAP library (e.g., php-ldap) for a custom solution.
3. What is the migration path if we proceed?
   • Option 1: Fork, modernize, and maintain (high effort).
   • Option 2: Build a new Laravel package from scratch (lower risk).
4. Are there legal/compliance risks with AGPL-3.0?
   • If the project is proprietary, ensure source code disclosure is acceptable.
5. What are the failure modes if we integrate this?
   • LDAP outage → No identity verification.
   • CampusOnline API changes → Bundle breaks silently.
   • Symfony/Laravel version conflicts → Deployment issues.

Integration Approach

Stack Fit

• Laravel Compatibility:
  • Low – Not natively supported; requires Symfony Bridge (symfony/flex) or manual adaptation.
  • Recommended Alternative: Use Laravel’s built-in HTTP client + LDAP extension (ext-ldap) for a native solution.
• Dependency Conflicts:
  • May pull in old Symfony versions (e.g., Symfony 5.x), which could conflict with Laravel’s dependencies.
  • Solution: Use Composer’s replace or conflict constraints to isolate dependencies.
• Service Integration:
  • If using, would likely fit into:
    • Laravel’s Service Container (as a bound service).
    • Laravel Events (if using Symfony’s EventDispatcher via a wrapper).
    • Custom Facade for API/LDAP interactions.

Migration Path

Compatibility

• Laravel Versions:
  • No official support for Laravel 10.x/11.x.
  • Workaround: Use Symfony 6.x (closest to Laravel’s modern stack) but still high risk.
• PHP Versions:
  • Likely PHP 7.4–8.0 (based on Symfony 5.x).
  • Laravel 10+ requires PHP 8.1+ → Potential deprecation warnings.
• Database:
  • No DB interactions in this bundle, but LDAP is a dependency.

Sequencing

1. Phase 1: Evaluation (1–2 weeks)
   • Confirm if CampusOnline/LDAP is still needed.
   • Check Austrian Government’s API documentation (if available).
2. Phase 2: Proof of Concept (2–3 weeks)
   • Option A: Try integrating the bundle via Symfony Bridge.
   • Option B: Build a minimal Laravel alternative (recommended).
3. Phase 3: Full Integration (3–4 weeks)
   • Refactor for Laravel (if proceeding with Option A).
   • Or complete custom package (Option B).
4. Phase 4: Testing & Deployment (2 weeks)
   • Unit/Integration tests for LDAP/API calls.
   • Load testing (if high traffic expected).
   • Rollout in staging, monitor failures.

Operational Impact

Maintenance

• High Effort:
  • No upstream maintenance → All fixes must be custom-patched.
  • LDAP schema changes may break the bundle.
  • CampusOnline API deprecations will require manual updates.
• Recommended:
  • Deprecate if possible → Replace with a modern identity provider (e.g., Keycloak, Auth0).
  • If keeping, assign a dedicated maintainer for LDAP/API monitoring.

Support

• Limited Debugging Resources:
  • No community support (1 star, archived).
  • No issue tracker activity → Problems may go unresolved.
• Workarounds:
  • Logging: Add detailed logs for LDAP/API failures.
  • Circuit Breaker: Use Laravel’s spatie/fork or fruitcake/laravel-pipeline to handle API outages.
  • Fallback Mechanism: Cache responses or use static placeholders if CampusOnline is down.

Scaling

• Performance Bottlenecks:
  • LDAP queries can be slow if not optimized.
  • CampusOnline API calls may have rate limits (undocumented).
• Scaling Strategies:
  • Queue API calls (Laravel Queues + Redis).
  • Cache responses (Laravel Cache + tags for invalidation).
  • Load-balance LDAP reads if using a replicated LDAP server.

Failure Modes