Iam Laravel Package

Product Decisions This Supports

• IAM domain modeling (build vs. buy input). The package is the reference implementation of the gdbots:iam schemas — users, roles, permissions, and the relationships between them. Even if you never install it, the schema surface tells you how much entity modeling a real identity system requires. Use it to size your own build effort before you commit to a custom RBAC layer.
• Schema-first vs. ORM-first architecture. This package exists because the domain is defined in protobuf/JSON schemas (PBJ) and PHP classes are generated from them. That is a concrete alternative to Eloquent migrations + models. If you are deciding how to keep API contracts, persistence, and events in sync, this is a useful counter-example in the architecture review.
• Event-sourced identity roadmap. It only makes sense alongside gdbots/pbj, gdbots/ncr, and gdbots/curator. If your roadmap already contains an event-sourced or CQRS backbone, this package determines the ordering of that work (schemas → persistence → projections → IAM). If it does not, adopting this forces a much larger platform bet than the IAM feature alone implies.
• RBAC vs. ABAC vs. ReBAC scoping. Reviewing the schema definitions reveals how coarse the permission model is. That informs whether you need fine-grained/resource-level authorization (which this model likely does not give you) and therefore whether you need a policy engine or relationship store on top.
• Multi-tenancy and delegation scope. Whether tenants, applications, and delegated admin are first-class in the model is a product decision (B2B vs. B2C, self-serve org management) that is expensive to retrofit. Reading the schemas is a cheap way to pressure-test your requirements before they are baked into your own data model.
• Runtime floor and platform coupling. v3.0.0 exists solely to move the package to PHP 8.1 — and it was shipped as a major version, i.e. 2.x is now a dead end for anyone on PHP 8.0 or below. That is a useful data point for "what does a dependency's PHP support policy cost us," and it sets a hard floor on the runtime version of any service that consumes it. Expect the same pattern (major bump, no feature work) for each future PHP release.
• Lock-in and coupling quantification. The package is a clean example of a "stack, not a library" dependency. It gives you a defensible number for the cost of schema-driven stacks when comparing against a managed IdP or a plain Laravel package.
• Due-diligence artifact. v3.0.0 (PHP 8.1 support) is the first release since December 2021 — a single maintenance commit after a multi-year gap, with no new features, 0 stars, 0 dependents, and single-ecosystem scope. For a security-critical domain, "alive enough to bump a version, not alive enough to have a maintainer roster or a CVE process" is a supply-chain datapoint worth putting in the decision record, not a hidden assumption.

When to Consider This Package

Consider it when all of the following are true:

• You are already running the gdbots stack (pbj, ncr, curator) and storing to Cassandra or DynamoDB. Then this is the missing typed layer, not a new platform.
• You need the IAM entity definitions as data contracts across services, and protobuf/JSON schema generation is already in your build pipeline.
• You are on PHP 8.1 or newer and are comfortable that the package's runtime floor will only ever move in breaking major bumps (and will lag current PHP by months or years).
• You want an Apache-2.0 starting point to fork — a schema and class skeleton for your own identity model — and you are prepared to own it permanently.
• You are running a time-boxed architectural spike on event-sourced IAM in PHP and want a worked example rather than a blank page.

Look elsewhere when any of these are true (which, for most Laravel teams, will be all of them):

• You need working authentication this quarter. This is not an auth package: there is no Laravel service provider, no config file, no migrations, no guards, no middleware, no OIDC/SAML/MFA/passkey support. Integration is manual wiring against a schema layer.
• You want a maintained dependency. A single PHP-version-bump release after a three-year silence is a sign of life, not a support commitment: no feature roadmap, no dependents, no community, no published security policy. A security defect in an identity library is not something you want to fix upstream-less; you would be forking on day one.
• You are pinned to PHP 8.0 or earlier — v3.0.0 drops you, and 2.x receives no further patches.
• You have no Cassandra/DynamoDB infrastructure, or you object to protobuf code generation in your CI pipeline.
• You need team-scale contribution, documented upgrade paths, or vendor support to satisfy SOC 2 / ISO 27001 evidence requirements.
• Your actual need is authorization only. Laravel's Gate/Policy plus spatie/laravel-permission or bouncer covers RBAC with a maintained, well-understood dependency; laravel/sanctum or laravel/passport covers tokens; a managed IdP (Auth0, Keycloak, Ory, Cognito, WorkOS) covers the rest with people contractually responsible for it.

The honest default recommendation is unchanged by v3.0.0: do not add this as a dependency. Consume it as a design input.

How to Pitch It (Stakeholders)

To executives: This is not a product we should adopt — it is a well-structured blueprint for how someone else modeled identity and access management in PHP. It is free (Apache-2.0), small, and has effectively zero adoption. It did just publish a new major release, but the entire change is "now requires PHP 8.1" — no new capability, no security fix, no maintainer team behind it, and it is the first release in over three years. For a security-critical area like login, roles, and permissions, that is the wrong dependency to take on, and the version bump does not change that. What it is good for is saving us a week or two of schema design: we can read their entity model, confirm we have not missed anything (tenants, delegated admin, permission granularity), and then build on packages we actually control. My recommendation is a short, capped evaluation — a day or two of one engineer's time — with no production dependency, and a decision record that documents why we passed. If we are already deep in the gdbots event-sourcing stack, that changes the math and we should revisit, but even then I would vendor and own a fork rather than depend on it.

To engineering: Treat it as a reference spec, not a library. v3.0.0 is a single breaking change — PHP 8.1 support — which tells you two things: the project is not abandoned outright, but its maintenance cadence is measured in years, and its runtime support arrives as a major bump with no migration guide. Plan for it to lag PHP 8.2/8.3/8.4 similarly. It only functions inside the gdbots ecosystem — pbj for schema compilation, ncr for persistence, curator for event sourcing — so pulling it into a conventional Laravel app means hand-wiring serialization, storage, and projections with no service provider, config, or migrations to lean on. The Apache-2.0 license means we can fork the schemas freely; the 0-star, 0-dependent, single-commit-per-release profile means we would have to. Concretely: lift the entity model into our own Eloquent/spatie/laravel-permission design, note the gaps (fine-grained permissions, multi-tenancy), and keep the security-critical path on dependencies with active maintainers and a CVE process. If you want the event-sourced variant, put it behind a spike with an explicit exit criterion and a named owner.