Crowd Bundle Laravel Package

Getting Started

First, a reality check that shapes everything below: smurfy/crowd-bundle is a Symfony bundle, not a Laravel package. It wires Atlassian Crowd into Symfony's Security component via a custom user provider / authentication provider. As a Laravel developer you will not composer require this into a Laravel app and expect it to work — there is no service provider, no guard, and it depends on Symfony's SecurityBundle internals. Treat it as a reference implementation for how Crowd authentication is wired up, and port the pattern into a Laravel guard.

Minimal steps if you were on the matching Symfony version:

1. composer require smurfy/crowd-bundle (expect it to pull Symfony 2.x-era constraints).
2. Register AsaAyers\CrowdBundle\AsaAyersCrowdBundle in app/AppKernel.php.
3. Configure the Crowd application credentials (Crowd base URL, application name, application password) plus the firewall in config.yml.
4. Point a form_login firewall at the Crowd user provider, then log in with a real Crowd username/password.

Where to look first: the bundle's DependencyInjection/Configuration.php (it defines the exact config keys), the security factory that builds the provider, and the README. Those three tell you the request shape, the config contract, and the expected Symfony version.

First use case for a Laravel dev: replicate the login call. Crowd's user authentication endpoint is POST /rest/usermanagement/1/authentication?username={user} using the application name/password as HTTP Basic auth, with the user's password in a JSON body. That single call is the core of what this bundle does — everything else is Symfony plumbing around it.

Implementation Patterns

What the bundle actually provides (the pattern to copy):

• A user provider that authenticates against Crowd and maps a Crowd user to a Symfony UserInterface.
• A security factory so the provider can be referenced by name inside a firewall.
• Likely group-to-role mapping, translating Crowd group memberships into roles your app checks.
• Configuration for connection details (base URL, app name, app password) and caching of user/group lookups.

Laravel translation of each pattern:

• User provider → a custom Illuminate\Contracts\Auth\UserProvider or, more simply, a Guard that calls Crowd and then resolves/creates a local User row keyed by Crowd username. Keep Crowd as the source of truth for credentials, Laravel as the source of truth for authorization data.
• Firewall config → a named guard in config/auth.php plus a crowd driver in Auth::extend().
• Group-to-role mapping → sync Crowd groups into local roles/permissions on login (or on a scheduled job), rather than trusting Crowd on every request.
• Config → a config/crowd.php with base_url, app_name, app_password, timeout, and a cache_ttl, mirrored from the bundle's Configuration.php.

Recommended workflow: authenticate on login only, then issue a normal Laravel session. Do not call Crowd on every request — it becomes a hard dependency on an external SSO server for every page load. Cache the Crowd user payload (user + groups) keyed by username with a short TTL, and invalidate on logout or a password_changed webhook if you have one.

Integration tips: wrap the Crowd HTTP calls in a small dedicated client class (Laravel's Http facade is fine) so you can unit-test the guard with a fake client. Store the app password in .env, never in the committed config. If the bundle exposes a service for programmatic auth, note that pattern — in Laravel the equivalent is Auth::guard('crowd')->attempt($credentials).

Gotchas and Tips

• Maintenance risk is the headline. 1 star, 0 dependents, a score of ~0.005. This is effectively unmaintained and unproven. Do not make it a production dependency; vendor or reimplement the logic.
• Symfony/PHP version lock-in. This style of bundle is built for Symfony 2-era security APIs and likely PHP 5.x/7.0-era code. It will not install cleanly alongside modern Symfony, and definitely not in Laravel. Pin nothing — just don't use it directly.
• App credentials are not user credentials. Crowd requires an application registered in the Crowd admin console with its own name/password; the user's password is separate. Getting a 401 usually means the application credentials or the app's "allow all users" / directory permissions are misconfigured, not that the user's password is wrong.
• TLS is a common wall. Self-signed Crowd instances cause certificate failures. Fix the trust store rather than disabling verification; if you must, gate it behind a config flag and never default it on.
• Group/role staleness. If the bundle caches group membership, role changes in Crowd won't propagate until the cache expires or the session is refreshed. Decide explicitly: trust on login only (cheap, stale) vs. re-check per request (fresh, fragile).
• Debugging path: when auth fails, isolate the layers in order — (1) can you curl the Crowd auth endpoint with the app credentials? (2) does the user exist in Crowd and in the correct directory? (3) is the bundle's firewall config even being loaded (check the resolved container/config dump)? Symfony security debug tooling and Crowd server logs tell you which layer broke.
• Extension points to borrow: the user provider and group mapper are the two seams worth copying. Override or decorate the group mapper if you need custom role naming; that mapping is where most app-specific logic lives.
• Timeouts and availability. Crowd is a single external dependency for login. Set aggressive connect/read timeouts and decide what happens on outage — locked-out users, or a fallback local-auth path. The bundle won't decide this for you, and neither will a naive Laravel port.
• If you just want Crowd SSO in Laravel, skip this package entirely and implement a guard against the Crowd REST API directly. The surface area you need is small: one authentication call, one user lookup, one group-membership lookup. That is a few hundred lines and fully under your control, versus depending on an unmaintained Symfony bundle.