Sso Auth Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony2 Focus: The package is explicitly designed for Symfony2, which may introduce version compatibility risks if migrating to Symfony 4/5/6+ (LTS). A TPM must assess whether the project’s roadmap aligns with Symfony2’s end-of-life (EOL) or if a fork/maintenance plan exists.
• SSO Protocol Support: Currently only CAS (Central Authentication Service) is implemented, limiting use cases. If the project requires SAML, OAuth2, or OpenID Connect, this package may need supplementation (e.g., via onelogin/php-saml or league/oauth2-server).
• Bundle Architecture: Follows Symfony’s Bundle pattern, meaning it integrates via AppKernel.php or config/bundles.php. This is low-risk for Symfony2 but may require refactoring for modern Symfony (e.g., auto-wiring, Flex recipes).
• Security Considerations:
  • CAS is stateful and requires careful session management.
  • No built-in multi-factor authentication (MFA) or adaptive auth support.
  • Token handling (e.g., session fixation, CSRF) must be validated against Symfony’s security component.

Integration Feasibility

• Dependency Graph:
  • Requires symfony/security-core (v2.x), symfony/http-foundation, and php-cas (for CAS).
  • No PHP 8.x support (Symfony2’s EOL is 2023, but PHP 8.x breaks BC).
  • Composer constraints may conflict with modern Laravel/PHP stacks if cross-language integration is needed.
• Authentication Flow:
  • Trusted Mode: Relies on a pre-configured CAS server (e.g., Apache CAS, Jasig CAS). Requires network-level trust (e.g., same domain or VPN).
  • Open Mode: Uses OpenID (deprecated in favor of OpenID Connect). May need replacement for modern SSO.
• Database/ORM: No direct DB requirements, but user provider integration (e.g., UserProviderInterface) is mandatory. Assess whether existing user models align with Symfony’s UserInterface.

Technical Risk

Key Questions

1. Symfony Version: Is the project locked to Symfony2, or can it migrate to Symfony 5/6+?
2. SSO Protocol Requirements: Is CAS sufficient, or are SAML/OAuth2/OIDC needed?
3. Existing Auth Stack: Does the current system use Symfony’s security component, or is a hybrid approach needed?
4. CAS Server Availability: Is there an in-house CAS server, or will a third-party (e.g., PennState CAS) be used?
5. Performance: Will CAS proxy requests introduce latency for high-traffic endpoints?
6. Compliance: Does the organization require FIDO2, MFA, or audit logs beyond CAS?
7. Fallback Auth: How will authentication work if the CAS server is down?

Integration Approach

Stack Fit

• Symfony2 Projects: Direct fit with minimal configuration (follow documentation).
• Laravel Projects: Not natively compatible due to:
  • Symfony-specific components (e.g., SecurityBundle).
  • Laravel’s service container differs from Symfony’s DI.
  • Workaround: Use the underlying php-cas library directly or build a Laravel wrapper.
• Hybrid Stacks: If integrating with a Symfony2 microservice alongside Laravel, consider:
  • API Gateway Pattern: Expose CAS-authenticated endpoints via Symfony2, consumed by Laravel.
  • Shared Session Store: Use Redis/Memcached for session synchronization.

Migration Path

1. Symfony2 Projects:
   • Install via Composer: composer require besimple/sso-auth-bundle.
   • Configure config.yml and security.yml per docs.
   • Test with a staging CAS server before production rollout.
2. Laravel Projects:
   • Option A: Use php-cas directly:

     use PhpCas\AuthenticationFilter;
     use PhpCas\Service;
     

   • Option B: Create a Laravel Service Provider to mimic Symfony’s bundle structure.
   • Option C: Use a reverse proxy (e.g., Nginx) to handle CAS auth before Laravel.
3. Legacy Systems:
   • If migrating from custom auth, ensure user roles/groups map correctly to Symfony’s UserInterface.

Compatibility

Sequencing

1. Phase 1: Proof of Concept (PoC)
   • Set up a local CAS server (e.g., Apache CAS).
   • Test bundle in a Symfony2 dev environment.
   • Validate user provisioning and role mapping.
2. Phase 2: Integration
   • Configure Symfony security.yml for CAS/OpenID.
   • Implement fallback auth (e.g., form login if CAS fails).
   • Test with load balancers/proxies (CAS may need X-Forwarded-* headers).
3. Phase 3: Deployment
   • Roll out to staging with monitoring for CAS timeouts.
   • Gradually migrate legacy auth endpoints to SSO.
4. Phase 4: Optimization
   • Cache CAS tickets if latency is high.
   • Add logging/auditing for compliance.

Operational Impact

Maintenance

• Bundle Updates: No active maintenance (last commit ~2017). Fork or patch if issues arise.
• Dependency Risks:
  • php-cas may have vulnerabilities (monitor CVE).
  • Symfony2’s security component is stable but unsupported.
• Documentation: Outdated; internal runbooks should document:
  • CAS server troubleshooting.
  • User deprovisioning workflows.
  • Fallback auth procedures.

Support

• Vendor Lock-in: Tied to Symfony2’s ecosystem; no multi-cloud SSO (e.g., Azure AD, Okta) support.
• Debugging:
  • CAS failures may require network packet capture (Wireshark).
  • Symfony’s security.debug must be enabled for logs.
• Support Channels:
  • GitHub issues are inactive; rely on community forks or Symfony forums.
  • Consider commercial CAS support (e.g., Gluu, Ping Identity).

Scaling

• Horizontal Scaling:
  • CAS tickets are session-based; ensure sticky sessions in load balancers (e.g., Nginx ip_hash).
  • Stateless CAS: If using token-based auth, scale horizontally without session affinity.
• Performance Bottlenecks:
  • CAS proxy requests may add latency (~100–300ms per auth).
  • Solution: Cache validated tickets or use edge-side auth (e.g., Cloudflare Access).
• Database Load:
  • No direct DB impact, but user provider queries may scale with user count.

Failure Modes