One authorization service for many applications, built in Rust with Casbin
Access rules held in one service and decided inside each application from a cached copy, chosen by benchmarking five frameworks and integrated one application at a time.
- Partner
- A multinational advisory firm
- Period
- Under 2 months
- Frameworks compared
- 5
- OPA, OpenFGA, SpiceDB, Cerbos and Casbin
- Decisions
- In process
- No network call on the request path
- Delivery
- <2 months
- From framework review to integration
The challenge
Each application held its own authorization logic. The same rules were implemented several times, changes needed code updates in every application, and some checks queried a database on every request in performance-sensitive services.
What we built
A central policy service in Rust using Casbin, chosen after benchmarking five open-source frameworks. Applications decide access in process from a cached copy of the policies, which the service updates within seconds of a change, so rules live in one place without adding a network call to each request.
What was delivered
- One source of truth for access rules across the integrated applications
- Policy changes applied centrally, without application releases
- Access decided in process, with no network call per request
Partner background
Our partner is a multinational advisory firm serving high-profile organizations, which sets a high standard for application security. Its applications serve shared data resources, and it needed fine-grained, consistent control over who can access them.
The challenge
Authorization in every application
Each application implemented its own access rules. The same rule existed in several places and could drift apart.
Latency on every request
Some applications, including Python services for machine learning, queried a database for every access check, which added time to every request.
Rules locked in code
Changing a policy meant changing and releasing every affected application, which turned small changes into coordination across teams.
Central, but not slower
Moving rules into a separate service usually adds a network call to every request. The design had to centralize the rules without that cost.
Objectives
- Consolidate authorization rules into one service that every integrated application uses
- Decide access without adding a network call to each request
- Change rules without redeploying applications
- Keep applications working if the policy service is briefly unavailable
- Separate authorization concerns from application code
Our role
CharCentric compared and benchmarked the candidate frameworks, built the service and integrated it with the partner's applications, in under two months.
Scope and timeline
The project began with a comparison of five open-source authorization frameworks, including benchmarks and proofs of concept, followed by implementation and integration. The work was completed in under two months.
Approach
Choose with evidence
OPA, OpenFGA, SpiceDB, Cerbos and Casbin were compared on how well their policy model fitted the partner's resources, on decision latency and on the cost of running them, and tested in proofs of concept. Casbin was chosen because it keeps rules as data that can change at runtime and can decide inside the application.
Central rules, local decisions
The Rust service is the source of truth for policies. Each application holds a cached Casbin enforcer and receives policy changes through a watcher over Redis publish and subscribe, so a check is a local lookup rather than a network call. Each application also reloads the full policy set when it reconnects and at a fixed interval, so a missed message cannot leave it out of date.
Rust for the service
Rust gives the policy service predictable performance and low memory use, and casbin-rs implements the same Casbin model that the applications enforce.
Implementation
Framework review and benchmarks
Open-source frameworks were reviewed for capability and benchmarked for performance, with proofs of concept against the partner's requirements.
Central service
Built in Rust with casbin-rs, the service stores policies, validates changes and publishes them to every connected application. It runs on Azure Container Apps with at least three replicas.
Failure behaviour
Applications keep deciding from their cached policies if the service is unavailable, and refuse access if they cannot load policies from the service when they start.
Integration
Resource data models were decoupled from application logic and described in the policy service. Applications were connected one at a time to avoid disrupting operations.
Tools and technologies
| Tool | Purpose |
|---|---|
| Rust and casbin-rs | Policy service |
| Casbin | Policy model and in-process enforcement |
| Redis publish and subscribe | Policy change notifications |
| Azure Container Apps | Hosting, with at least three replicas |
What was delivered
- Frameworks compared
- 5
- Decisions
- In process
- Policy changes
- Runtime
- Delivery
- <2 months
- A central policy service used by the partner's applications
- Policy changes without application redeployment
- Access decided in process from cached policies
- A framework choice backed by benchmarks and proofs of concept
Why it matters
Authorization rules tend to multiply quietly across applications until no one can say with confidence who can access what. Centralizing them restores that answer and makes every future policy change a single, controlled step.
If your organization is facing a similar challenge, we would be glad to discuss it.