Shibboleth Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony 2.1+ Compatibility: The bundle targets Symfony 2.1+, which aligns with most modern Laravel applications only if using Lumen (Symfony-based) or via Symfony Bridge (e.g., symfony/http-foundation). For vanilla Laravel, this is a poor fit due to fundamental architectural differences (e.g., no FOSUserBundle, no Symfony kernel).
• Shibboleth-Specific Logic: The bundle abstracts Shibboleth SP (Service Provider) integration, including SAML assertions, attribute mapping, and session handling. If Laravel needs SAML/OIDC, alternatives like onelogin/php-saml or league/oauth2-server are more idiomatic.
• FOSUserBundle Dependency: Tight coupling with FOSUserBundle (Symfony’s user management) makes this non-portable to Laravel’s built-in Auth or packages like laravel/breeze.

Integration Feasibility

• Laravel-Symfony Bridge: Possible via:
  • Symfony HTTP Kernel: Embedding Symfony components (high complexity, maintenance overhead).
  • API Wrapper: Exposing Shibboleth logic as a microservice (recommended for Laravel).
• SAML Middleware: Laravel lacks native SAML support; integrating this bundle would require custom middleware to parse Shibboleth headers (REMOTE_USER, HTTP_SHIBBOLETH_*).
• Database Schema: Assumes FOSUserBundle’s schema; Laravel’s users table would need manual alignment or a migration layer.

Technical Risk

• API Instability: Active development with no API guarantees could break integrations.
• Dependency Bloat: Pulls in Symfony components (e.g., symfony/security, symfony/dependency-injection) that may conflict with Laravel’s DI container.
• Testing Gaps: Low stars/dependents suggest unproven reliability in production.
• Lack of Laravel-Specific Docs: No guidance on adapting Symfony-specific features (e.g., event listeners, services) to Laravel’s context.

Key Questions

1. Why Shibboleth? Could OAuth2/OIDC (via socialiteproviders) or CAS suffice?
2. Symfony Dependency Tolerance: Is the team open to a polyfill layer or microservice approach?
3. User Model Compatibility: How will FOSUserBundle’s schema map to Laravel’s users table?
4. Maintenance Plan: Who will handle Symfony/Laravel compatibility drift?
5. Fallback Auth: How will non-Shibboleth users authenticate (e.g., email/password)?

Integration Approach

Stack Fit

• Symfony vs. Laravel: This bundle is Symfony-native; Laravel integration requires:
  • Option 1: Symfony Bridge (e.g., spatie/laravel-symfony-support) to reuse components.
  • Option 2: SAML Library (e.g., onelogin/php-saml) for a Laravel-first solution.
  • Option 3: Microservice (e.g., PHP SAML SP as a separate service consumed via HTTP).
• FOSUserBundle Alternative: Replace with Laravel’s built-in Auth or laravel/ui for user management.

Migration Path

1. Assessment Phase:
   • Audit current auth flow (e.g., does it use FOSUserBundle-like patterns?).
   • Test Shibboleth headers (REMOTE_USER) in Laravel’s middleware.
2. Proof of Concept:
   • Spin up a Symfony 2.1+ app with this bundle to validate Shibboleth SP behavior.
   • Mock Laravel’s request lifecycle to ensure header parsing works.
3. Integration Steps:
   • Phase 1: Add Symfony components as Laravel services (e.g., HttpFoundation for headers).
   • Phase 2: Create a custom ShibbolethAuthenticator extending Laravel’s Authenticatable.
   • Phase 3: Map Shibboleth attributes to Laravel’s users table (e.g., email, name).
4. Fallback: Implement hybrid auth (Shibboleth + email/password) via middleware.

Compatibility

• Symfony Components: Laravel’s service container may reject Symfony’s DI definitions (e.g., services.yaml).
  • Mitigation: Use symfony/dependency-injection in a standalone container or adapt to Laravel’s bind().
• Event System: Symfony events (e.g., security.interactive_login) won’t natively trigger in Laravel.
  • Mitigation: Dispatch Laravel events (Authenticated) from custom listeners.
• Session Handling: Shibboleth relies on Symfony’s session; Laravel’s session may need extension.

Sequencing

Operational Impact

Maintenance

• Symfony Drift: Laravel and Symfony evolve independently; this bundle may require forking or rewriting core logic.
• Dependency Updates: Symfony 2.1 is EOL; upgrading to Symfony 5+ could break compatibility.
• Laravel-Specific Bugs: Issues like session handling or event dispatching will need custom patches.

Support

• Limited Community: No stars/dependents imply no community support.
• Debugging Complexity: Stack traces will mix Symfony and Laravel frameworks, complicating diagnostics.
• Vendor Lock-in: Tight coupling with FOSUserBundle may require maintaining a Symfony compatibility layer.

Scaling

• Performance: SAML assertions add latency; ensure Laravel’s middleware pipeline doesn’t bottleneck.
• Horizontal Scaling: Shibboleth sessions are typically sticky; Laravel’s statelessness may require session affinity (e.g., Redis).
• Load Testing: Validate attribute mapping under high concurrent logins (e.g., 1000+ RPsM).

Failure Modes

Ramp-Up

• Learning Curve: Team must learn:
  • Symfony’s event system and security components.
  • SAML protocol intricacies (e.g., metadata, assertions).
  • Laravel-Symfony interop patterns.
• Documentation Gaps: Bundle’s docs assume Symfony; custom runbooks needed for Laravel.
• Onboarding Time: 4–8 weeks for a small team to prototype and stabilize.
• Training Needs:
  • Symfony fundamentals (e.g., services, events).
  • SAML debugging (e.g., using simplesamlphp for testing).