jCasbin: a Java authorization library that treats policy as configuration

The problem jCasbin solves: authorization rules that outlive the code that checks them

Most Java services start with authorization scattered through controllers: an if statement here, a role string comparison there. That works until the rules change, and then the change has to be found in every place a check was written. jCasbin moves the decision out of the code. The README describes the project as an access control library for Java projects that enforces authorization based on access control models, and the supported list is broad: plain ACL, ACL with a superuser, ACL without users or without resources, RBAC, RBAC with resource roles, RBAC with domains or tenants, ABAC using attribute syntax such as resource.Owner, RESTful path and method matching, deny-override, and priority-ordered rules. The intended reader is a backend engineer who owns authorization for an application and wants the rules expressed once, in a file, rather than reimplemented per endpoint. The model is the same one Casbin uses in Go, Node, Python, PHP, .NET, C++ and Rust, which matters if your organization runs more than one language: a policy written for the Java library is meant to be readable by the others.

How the model file and policy file combine at request time

The README states that an access control model is abstracted into a configuration file, and the repository confirms this with examples/basic_model.conf, examples/rbac_model.conf and the ABAC variants. A request is a tuple, typically subject, resource and action, and the enforcer answers whether that tuple is allowed. The model file supplies the structure: the request definition, the policy definition, the role or matcher definitions, and an effect that says how matching rules combine. The policy file supplies the data, one row per rule. At enforcement time the enforcer evaluates the matcher against the request and the stored rules and returns a boolean. Because the matcher is an expression, the same engine covers RBAC (through role links resolved by a role manager) and ABAC (through attributes reached on the request objects, as in the resource.Owner form the README names). The repository ships separate example files for each shape, including examples/abac_rule_model.conf with examples/abac_rule_policy.csv, and examples/abac_rule_with_domains_model.conf for the multi-tenant case. That file pairing is the whole architecture: nothing about your users is compiled in, and nothing about your rules is hidden in annotations.

Installing jCasbin from Maven Central and enforcing your first request

The README's installation section points at Maven Central, and the badge links to the org.casbin/jcasbin artifact. Add the dependency to your build. The version shown here is the one named in the recent releases, and 1.100.0 is still in release-candidate and snapshot form, so check Maven Central for the current stable version before pinning.

Where jCasbin stops and other tools take over

jCasbin is a decision library, not an identity system. It does not authenticate users, store credentials, issue tokens, or manage a directory. The README's policy persistence section exists because the library itself does not know where your rules live: adapters do that job, and the related searches around Casbin adapters and a MongoDB adapter reflect how much of real deployment is adapter selection rather than model design. If your policy must be edited by non-engineers through a UI, or must be centrally audited across dozens of services, jCasbin gives you the evaluation engine but not the control plane. The README also does not document rollback of a bad policy change, so treat policy deployment as your problem. A second limitation is versioning: the newest published artifacts at the time of writing are 1.100.0-rc1 and two 1.100.0 snapshots, which means the leading edge of this library is a pre-release line, and teams with strict dependency policies should confirm what is actually stable before adopting.

jCasbin compared with Spring Security and with Open Policy Agent

Spring Security is the default answer for Java authorization, and its approach is different in kind: rules are attached to the application through configuration and method annotations, evaluated inside the Spring filter chain, and they assume Spring's own authentication context. jCasbin has no framework dependency and no opinion about how the caller was authenticated; you pass a request tuple and get a decision. That makes it usable in a plain library, a batch job, or a service that authenticates elsewhere, but it also means you wire the enforcement point yourself. Open Policy Agent takes the third route: policy is written in a separate language, evaluated by a sidecar or library, and the policy bundle is distributed independently of the application. jCasbin keeps policy in the same model-plus-CSV shape that its sibling implementations use across languages, which is simpler to read and to diff, while OPA's model is built for centralized policy distribution and richer query results. If your rules are per-service and change with the service, jCasbin is the lighter fit. If policy must be authored once and pushed to many heterogeneous services, the distribution story is the deciding factor.

Licence, governance and the cost of keeping up

The repository is licensed under Apache-2.0 and carries the ASF headers, NOTICE and DISCLAIMER files, and the project lives under the apache organization on GitHub, with BUILDING.md and RELEASING.md at the top level describing how it is built and released. For adopters this is a permissive licence with an explicit patent grant and no copyleft obligation on your own code; the usual Apache-2.0 notice requirements apply, and if you redistribute the library you should read the NOTICE file rather than rely on a summary. Upgrade cost is modest but not zero. The API surface is small and centered on the enforcer, the model and the policy, so patch releases rarely require code changes. The larger cost sits in the model and policy files: changing a matcher or an effect can change decisions in ways that are invisible in a diff of Java code, which is why the repository's examples directory is worth reading as a set of testable shapes rather than as documentation prose. The last push to the repository was on 2026-09-20, and the newest release is a release candidate, so the project is moving; that also means you should pin a version and read the release notes before moving.

Editorial conclusion

Adopt jCasbin if your authorization rules change often, your Java service already owns its own user and role data, and you want the same model file to work in Go, Python or Node services. Do not adopt it as a replacement for an identity provider, and do not expect the README to explain how to load policy from your database: the adapter projects do that. Before committing, verify three things against the repository itself: that the 1.100.0 line is past its rc1 stage for your risk tolerance, that a maintained adapter exists for your policy store, and that the example model closest to your rules (start with examples/rbac_model.conf and examples/abac_model.conf) actually expresses them.

Frequently asked questions

Official sources

1. apache/casbin-jcasbin on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases