One authorization service for many applications, built in Rust with Casbin
A central service that evaluates access rules for every application, chosen through framework benchmarks and integrated incrementally without disrupting operations.
- Partner
- An international advisory firm
- Period
- Under 2 months
- Authorization service
- 1
- Shared by all integrated applications
- For rule changes
- No redeploy
- Policies updated centrally while applications run
- 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 checks added latency to performance-sensitive services.
What we built
A central authorization service in Rust using Casbin, selected after reviewing and benchmarking open-source frameworks. Rules can change without redeploying applications, decisions are cached, and resource data models moved out of the applications into the service.
What was delivered
- A single service answering access questions for every integrated application
- Policy changes applied centrally, without application releases
- Incremental integration with no disruption to ongoing operations
Partner background
Our partner is an international 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
Applications on performance-sensitive stacks, such as Python services for machine learning, paid the cost of authorization on every request.
Rules locked in code
Changing a policy meant changing and releasing every affected application, which turned small changes into coordination across teams.
Objectives
- Consolidate authorization into one service that all applications use
- Keep authorization fast enough not to affect application performance
- Change rules without redeploying applications
- Separate authorization concerns from application code
Our role
CharCentric reviewed 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 review and comparison of open-source authorization frameworks, including benchmarks and proofs of concept, followed by implementation and integration. Several options were presented to the partner, and the work was completed in under two months.
Approach
Choose with evidence
Candidate frameworks were compared on features, speed and fit with the partner's architecture, and tested in proofs of concept before a choice was made.
Casbin for flexible policies
Casbin keeps access rules as data, so policies can change at runtime, and it supports caching of decisions.
Rust for the service
Rust gives predictable performance with low overhead, and its ownership model prevents common memory errors, such as use after free, in safe code. The service runs on bare metal with few layers between it and the hardware.
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
With Casbin selected, the service was built in Rust with abstracted authorization logic, runtime rule changes and caching for low latency.
Integration
Resource data models were decoupled from application logic and moved into the service. Applications were connected one at a time to avoid disrupting operations.
Tools and technologies
| Tool | Purpose |
|---|---|
| Rust | Authorization service implementation |
| Casbin | Policy model and enforcement |
| Decision cache | Fast repeated authorization checks |
| Bare metal hosting | Deployment with minimal layers |
What was delivered
- Central service
- 1
- Policy changes
- Runtime
- Decisions
- Cached
- Delivery
- <2 months
- A central authorization service used by the partner's applications
- Policy changes without application redeployment
- Authorization logic and resource models removed from application code
- 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.