Abac Bundle Laravel Package

Product Decisions This Supports

• Authorization model selection (RBAC vs. ABAC): The strongest signal here isn't the bundle — it's the underlying php-abac library and the ABAC pattern it enables. If your roadmap includes requirements like "regional managers can approve refunds over $5k only during business hours, for accounts in their territory," role checks collapse into combinatorial policy sprawl. ABAC lets you express those as policies over subject/resource/environment attributes. This package is a lens for evaluating whether you need that expressiveness or whether Laravel's Gates/Policies plus spatie/laravel-permission covers 90% of your cases.
• Build vs. buy for the policy engine: Authorization is a classic "looks simple, becomes load-bearing" subsystem. A policy engine (attribute resolution, combining algorithms, obligation handling, policy evaluation caching) is weeks of engineering plus ongoing security review. Deciding to adopt an existing evaluator rather than hand-roll conditionals in middleware is a legitimate buy decision — this repo is evidence that the pattern is mature enough to have multiple implementations.
• Multi-tenant and per-resource data scoping: ABAC is often the right tool for row-level visibility ("users see records where record.tenant_id == user.tenant_id and record.classification <= user.clearance") — a recurring roadmap item for B2B SaaS and regulated verticals. Worth modeling before committing to a schema.
• Feature gating and entitlement logic: Attribute-based evaluation can unify plan-tier gating, beta flags, and contract-specific entitlements behind a single policy layer instead of scattered if ($user->plan === 'pro') checks.
• What it should not drive: Do not let this package influence a framework decision. It is a Symfony bundle, and per the description wraps php-abac into Symfony's DI container. If you are a Laravel shop, the bundle itself is irrelevant — the transferable asset is the framework-agnostic php-abac core, which you would wire manually (service provider + config file, roughly a day of work). Treat this as competitive/pattern intelligence, not a dependency candidate.

When to Consider This Package

Consider it if:

• Your application is Symfony (not Laravel) and you have already decided ABAC is the right model. The bundle's only real value is service-container wiring and configuration plumbing over php-abac.
• You need a reference implementation to pressure-test ABAC concepts — policy structure, attribute providers, evaluation semantics — before designing an internal authorization layer.
• You are doing a time-boxed spike to prove or kill an ABAC proposal, and a Symfony-native wrapper shortens the proof-of-concept.

Look elsewhere if:

• You are on Laravel. This is the decisive criterion. The bundle targets a different framework; you would take php-abac directly or evaluate Laravel-native options (spatie/laravel-permission for RBAC, Laravel Policies/Gates for rule-based checks, casbin/laravel-authz or spatie/laravel-permission-plus-custom-policies for hybrid models). Adopting a Symfony bundle in a Laravel codebase is a category error.
• Maturity and longevity matter — which for authorization they do. 15 stars, zero dependents, and a low composite score describe a project with no visible production adoption and a single-maintainer bus factor. Authorization code sits directly on your security boundary; you want a dependency with a disclosed vulnerability process, a release cadence, and an issue tracker that shows real users. This meets none of those bars.
• You need externalized or language-agnostic policy. If policies must be authored by non-engineers, shared across services in multiple languages, or audited centrally, look at Open Policy Agent (Rego) or AWS Cedar, or a relationship-based system like SpiceDB/OpenFGA if your problem is really ReBAC (sharing, hierarchies, "can view because they're an editor of the parent folder") rather than ABAC.
• You need enterprise-grade guarantees. No SLA, no commercial support, no security disclosure policy documented in the repo metadata.
• You cannot afford to vendor/fork it. If the evaluation shows a fit, plan to pin a specific commit or fork it internally, since upstream maintenance is unproven.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated a small open-source component for attribute-based access control. The strategic takeaway is that our authorization needs are approaching the complexity where scattered role checks become a maintenance and audit liability — this is worth a scoped design decision, not an immediate purchase. The package itself is not a candidate: it targets Symfony, we run Laravel, and at 15 stars with no downstream dependents it carries unacceptable supply-chain risk for security-boundary code. Recommendation: keep authorization on Laravel's native Gates/Policies in the near term, and fund a short spike to determine whether we need a policy engine (in-house, php-abac core, or OPA/Cedar) before the next multi-tenant or enterprise-tier commitment.

To engineering (the actual ask): Don't add this dependency. Read the php-abac core to understand attribute resolution and policy evaluation, then run a two-day spike comparing three paths: (1) extend Laravel Gates/Policies with a small attribute-evaluation helper, (2) wire php-abac core via a service provider, (3) prototype an OPA sidecar if policy authoring by non-engineers is on the roadmap. Deliverable is a recommendation memo covering expressiveness, performance under our real permission cardinality, auditability of decisions, and operational cost. Whatever we choose, authorization logic gets an owner, tests, and a documented policy change process — the failure mode here is not picking the wrong library, it's having no deliberate decision at all.