Permission Bundle Laravel Package

Product Decisions This Supports

• Whether to build in-house RBAC/permission infrastructure for a Symfony + API Platform microservice fleet, or buy/adopt an existing bundle. This package bundles the "declare permissions per service → export to central user service → aggregate per user" flow, so it directly informs build-vs-buy on federated permission aggregation.
• Authorization architecture choices for microservices: local permission declaration per service with a central aggregation point vs. centralized policy engine (OPA/Cedar). The package's model is "each service owns its permission keys; a user service is the source of truth for assignments" — a viable pattern if you don't want a full policy engine.
• Row-level / object-level scoping strategy: the included Doctrine SelfPermissionFilter and SelfPermissionInterface support row-level "only my records" filtering. This informs decisions about whether you need per-object scoping (multi-tenant dashboards, "my orders" endpoints) vs. plain resource-level permissions.
• API Platform version commitment: the package's usage is tightly coupled to API Platform 2.x annotation syntax (collectionOperations, security_post_denormalize, _api_resource_class). Adopting it pins your roadmap to APIP2 semantics; migrating to API Platform 3 (attributes) would require forking or rewriting the integration points.
• Test strategy and QA investment: the JWTMockTrait and UnitTestTrait helpers signal a testing-first posture — useful for deciding how much to invest in permission-matrix test coverage vs. manual QA for authorization.
• Build-vs-buy signals to weigh: 3 GitHub stars, 0 dependents, last release July 2021 — this is effectively a single-vendor internal tool made public. It supports a "reference architecture / borrow-the-ideas" decision more than a "take a dependency" decision.

When to Consider This Package

Consider (or at least study) it when:

• You are building Symfony microservices on API Platform 2.x and want a distributed permission model: each service declares its own keys, a central user service aggregates a user's permissions, and services fetch the aggregate by {user_id}.
• You want row-level "self" scoping via a Doctrine filter without writing a custom SQLFilter — the SelfPermissionInterface/SelfPermissionTrait pattern is a clean reference.
• You want JWT-claim-driven permission checks (JTI, user id, permission keys) exposed through a small injectable service (AccessToken), plus annotations to declare custom permissions on controller methods.
• You want authorization test scaffolding — the JWTMockTrait, UnitTestTrait, and unit-test config/data DTOs are genuinely useful patterns even if you reimplement them.
• You are evaluating a reference implementation of federated permissions to copy or fork.

Look elsewhere when:

• You need maintained, actively supported dependencies. Last release 2021, low adoption, tied to a Symfony/API Platform generation that has since moved on (annotations → attributes, API Platform 3). Expect fork-and-own.
• You are on API Platform 3 or Symfony 6.3+/7 — the annotation-based security wiring will need rework.
• You need Laravel — this is a Symfony bundle, despite any "Laravel/PHP" framing. Laravel teams should look at spatie/laravel-permission or a policy engine (OPA/Cedar) instead.
• You want a general-purpose, centrally managed authorization system (RBAC/ABAC/PBAC with admin UIs, audit trails, policy-as-code). A dedicated IAM/policy engine is a better fit than a microservice-to-microservice permission aggregation bundle.
• You need community support, security patches, or a clear maintainer commitment. Neither exists here.

How to Pitch It (Stakeholders)

To executives: This is a small, abandoned-but-useful Symfony bundle that shows how to run federated permissions across microservices — each service owns its permission keys, and a central user service aggregates them per user. Stars (3), dependents (0), and a 2021 last release mean we should treat it as a design reference, not a vendor dependency. Recommendation: adopt the pattern and a few classes (the Doctrine self-permission filter, the JWT access-token service, the test helpers) into an internal package we own, rather than adding a stale third-party dependency to production. Cost of adoption is low; cost of being stuck on it is high because it's pinned to API Platform 2.x annotation conventions. Expected effort to internalize: modest — most of the value is in a few hundred lines of straightforward Symfony/Doctrine code.

To engineering: It gives you a working blueprint for cross-service permissions on API Platform: epubli_permission.yaml config (microservice name, export route, aggregated-permissions route), the SelfPermissionFilter Doctrine filter for row-level "my records only" scoping, an injectable AccessToken service (JTI, user id, hasPermissionKey()), and @Permission annotations for declaring controller-level permissions with automatic service-name prefixes. The testing tooling (JWTMockTrait, UnitTestTrait, unit-test config DTOs) is worth reusing almost verbatim. Caveats: it targets API Platform 2.x annotations, is tied to the original author's l0wskilled/api-platform-test for tests, and has no maintainer activity since mid-2021. Pitch: vendor a trimmed fork (or re-implement the ~5 classes we actually need) with our own CI and API Platform 3 attribute support, and keep the permission-export/aggregation contract as documented internal API.