Sso Auth Bundle Laravel Package

Getting Started

First, the honest scoping: this is a Symfony 2 bundle, not a Laravel package. There is no service provider, no facade, no config/sso.php — composer require webnet/sso-auth-bundle inside a Laravel app gets you a class library that references Symfony\Component\Security\Core\SecurityContext, which no longer exists in any supported Symfony. So "getting started" splits into two very different paths:

Path A — you maintain a legacy Symfony 2.7/2.8 app that already talks to Webnet's SSO.

1. composer require webnet/sso-auth-bundle (pin the 2018 tag; the repo has had no release since 2018-06-26).
2. Register the bundle in app/AppKernel.php under $bundles.
3. Open DependencyInjection/Configuration.php first — it is the only reliable documentation for the config tree. The README is thin and the bundle has 1 star / 0 dependents, so there is no blog post or StackOverflow answer to fall back on.
4. Add the webnet_sso_auth: block to config.yml with your SSO endpoint + client credentials.
5. Wire a firewall in security.yml using the bundle's security factory (the factory key is defined in Security/Factory/*Factory.php::getKey() — copy it exactly).
6. Protect one low-risk route and confirm the redirect → callback → token handshake before touching your real login.

Path B — you are a Laravel developer evaluating whether to port it. Read it as a protocol reference, not a dependency. The useful artefacts are: the redirect URL shape, the parameter names, how the returned token is validated, and which SSO attributes map to which user fields. That's an afternoon of reading and it's the only durable value here.

First use case: a single admin back-office route in a legacy app, behind the SSO firewall, with the existing form login still working as a fallback. Do not start by replacing your primary authentication.

Implementation Patterns

Firewall-level integration (the intended pattern). The bundle plugs in as a Symfony security factory, so it lives alongside form_login in security.yml rather than as a controller. Expect the listener to intercept unauthenticated requests, redirect to the SSO endpoint, and handle the callback on a fixed path. Configure it as a separate firewall with its own pattern rather than bolting it onto your main firewall — this keeps the SSO redirect from swallowing API or asset requests.

Federated identity with local users. The realistic day-to-day pattern is: SSO proves who the user is, your database still owns what they can do. Implement a custom user provider that looks up by the SSO subject/email and JIT-provisions a local user on first login, assigning a conservative default role. Never let SSO-supplied roles map straight to ROLE_ADMIN — that turns a compromise of the IdP into a compromise of your app.

Coexistence with local auth. Keep form_login for service accounts and break-glass access, with the SSO firewall scoped by path. In practice SSO outages are the number-one operational incident with these bundles, and a bundle last released in 2018 will not be patched when it breaks.

Porting the handshake to Laravel. The rewrite is small and mostly mechanical:

• GET /auth/sso/redirect → build the authorize URL, stash state in the session, redirect out.
• GET /auth/sso/callback → constant-time compare state, exchange the token server-side, Auth::login($user, true), regenerate the session ID.
• Use Http (Guzzle under the hood) with a timeout and ->throw(), not raw file_get_contents.
• Wrap it in a named route group + auth middleware; Laravel's Authenticatable contract is your user provider equivalent.

Attribute mapping as an explicit table. Whatever the bundle does implicitly, write it down: SSO claim → local column → fallback. Email is not a stable identifier — use the subject/ID. This is the single most common source of "user logged in as the wrong person" bugs.

Gotchas and Tips

It won't install cleanly on modern PHP. The 2018 release targets PHP 5.6/7.0 and Symfony 2.x. Expect composer conflicts on PHP 8 (#[\ReturnTypeWillChange], removed mcrypt, deprecated dynamic properties) and on any Symfony package ≥ 3.0. If you're on Symfony 2.8 LTS, that branch itself went EOL in November 2018 — you are running an unpatched authentication stack.

The SecurityContext / Security split is the killer. Symfony 2.8 deprecated SecurityContext in favour of Security\Security, and getToken()/setToken() signatures changed. If the bundle calls the old API you'll get fatal errors on 2.8 and it simply won't run on 3+. Check Security/Authentication/Provider/ and the listener before you invest further.

Factory key mismatch is the classic first error. Unable to find security factory "webnet_sso" (or similar) means the key in security.yml doesn't match getKey() in the factory class. It is not a config problem and no amount of tweaking the webnet_sso_auth: block will fix it.

Redirect loops. If the SSO callback path itself falls under the SSO firewall's pattern, or the IdP endpoint isn't in access_control's anonymous: true set, you get an infinite bounce. Add - { path: ^/sso, roles: IS_AUTHENTICATED_ANONYMOUSLY } and verify with bin/console debug:router where the callback actually lands.

Listener order matters. The SSO listener must run before form login if you want SSO to win on shared paths; Symfony executes listeners in registration order within a firewall. If both are firing, split them into separate firewalls.

Debugging levers. security.access_control logging plus app/logs/dev.log at debug level is your only visibility — the bundle has no dedicated logging channel. For the handshake itself, log the redirect URL and the raw callback query string (redact the token) at info. That's usually enough to distinguish "IdP rejected us" from "we rejected the IdP."

Extension points worth knowing. The user provider and the authentication success handler are the two seams you'll actually need — swap the provider for local user lookup, and the success handler for post-login redirect/role sync. Neither requires forking the bundle, which is the one thing in its favour.

Verdict for day-to-day leverage: low. 1 star, 0 dependents, no release since 2018, and a Symfony-2-only surface means there is effectively no community to help you and no upstream to fix bugs. For a Symfony 2 app that's already integrated, reading it is fine; adopting it fresh is not. For anything modern, use knpu-oauth2-client or HWIOAuthBundle on Symfony, Laravel Socialite plus a generic OAuth2 provider on Laravel, and onelogin/php-saml / simplesamlphp if the Webnet endpoint is actually SAML rather than OAuth.