Kerberos Bundle Laravel Package

Product Decisions This Supports

• Enterprise SSO for internal apps. This bundle bridges server-level Kerberos/SPNEGO authentication (Apache mod_auth_kerb, mod_auth_gssapi, or nginx auth_gssapi) into the Symfony security layer. The product decision it enables is: do we support silent Windows/Active Directory login for internal users?
• Build vs buy (vs copy). The Kerberos handshake itself is not what this package solves — the web server does that. The package is a thin, opinionated adapter that maps a negotiated identity (typically REMOTE_USER / server variable) onto a Symfony user/token. That is genuinely a few dozen to a few hundred lines of glue, but it is fiddly glue that gets security-review attention. The decision is whether to spend an engineer-week on it or vendor a small reference implementation.
• Roadmap triage for "enterprise readiness." If your roadmap has an item like "SSO support," this package is a data point for the on-prem / Windows-domain branch of that decision — as distinct from the cloud-IdP branch (OIDC/SAML via Azure AD, Okta, Keycloak, Auth0).
• Use cases it actually fits: intranet dashboards, admin consoles, internal back-office tooling, and any Symfony app where the user is already domain-joined and the browser will auto-negotiate — i.e. zero-login-UI experiences for employees behind the corporate network.
• Framing correction worth flagging early: despite being scored as a Laravel/PHP package, this is a Symfony bundle. It provides no Laravel/Socialite/Guard integration. If your roadmap assumes Laravel, this package is not on the critical path — it's a reference design at best.

When to Consider This Package

Consider it when:

• The application is Symfony, not Laravel. There is no Laravel adapter here and wiring a Symfony bundle into Laravel is not a thing.
• You already operate a KDC / Active Directory domain and the web tier already terminates Kerberos (or you're prepared to configure it — that's the hard part, and it's outside this package).
• Users are on domain-joined Windows machines on the corporate network, where browsers negotiate SPNEGO automatically.
• You need the identity plumbing into Symfony's firewall/authenticator chain and want a worked example rather than a blank page.

Look elsewhere when:

• You are on Laravel, or on any stack where the framework integration isn't Symfony's security component.
• Your identity provider is a cloud IdP — Azure AD, Okta, Google Workspace, Auth0. Use OIDC or SAML; Kerberos is the wrong protocol for users off-network, on mobile, or on non-domain machines.
• You need anything resembling maintained, supported, audited authentication code. The signals here are stark: 3 stars, 0 dependents, low overall score. There is effectively no community, no downstream validation, no evidence of recent security review, and no support channel. Treat it as a reference implementation to read and fork, not a dependency to pin in composer.json for a production auth path.
• Your security posture requires CVE response commitments or a maintainer SLA. Nothing here offers that.
• Your users are external/public. Kerberos behind a corporate perimeter is the opposite of that use case.

Practical recommendation: clone it, read it, and either vendor the relevant authenticator into your own codebase with tests, or reimplement the ~100 lines of glue yourself. That gives you the concept without inheriting an unmaintained dependency on your authentication boundary.

How to Pitch It (Stakeholders)

For executives: This is a small, single-purpose Symfony component that lets internal applications accept a user's existing Windows/Active Directory login instead of asking for a separate password — the "no login screen" experience employees expect from intranet tools. The product value is reduced friction and fewer credentials floating around; the cost is that it only works for on-premises, domain-joined users on the corporate network, so it does not replace a cloud identity strategy. The component itself is a thin adapter around functionality the web server already provides. Given its minimal adoption (3 stars, no downstream dependents), I would not treat it as a production dependency. Recommendation: treat it as a design reference, budget roughly one engineer-week to absorb and own the equivalent logic in-house, and keep it scoped to internal tooling only.

For engineering: This is a Symfony bundle, not a Laravel package — flagging that up front since the intake record mislabels it. It assumes Kerberos is already terminated at the web tier (Apache mod_auth_gssapi or nginx equivalent) and its job is mapping the negotiated principal into Symfony's security/authenticator chain. The code surface is small and the operational complexity lives in the KDC and SPN configuration, not in the PHP. Because there are zero dependents and no maintenance signal, the ask is: read it, don't require it. Vendor the pattern with your own tests, or implement the adapter directly — that keeps our authentication boundary inside our own review and CVE process rather than outsourcing it to an unmaintained third party. If we do adopt, it should be a pinned fork with an owner, not a floating ^ constraint.