How does Darwan compare to Open Policy Agent?

OPA is a general policy engine deployed as a sidecar per service, with multi-tenancy and RBAC modelled in Rego by the application team. Darwan is opinionated for SaaS and regulated workloads: tenant isolation is first-class, RBAC and ABAC are layered with a deny-override rule, and a signed audit chain is built in. You operate one Darwan, not one OPA per service.

Does Darwan support attribute-based policies?

Yes. Policy sets are versioned, and each rule carries a JSON condition that runs against subject, resource, and request context. A typical use is restricting an invoice.read grant so a non-owner cannot read another department's invoice. Deny rules evaluate first, then allow rules. Deny always overrides allow.

Where does Darwan fit relative to Wenme?

Wenme answers who you are. Darwan answers what you may do. A request arrives with a Wenme-issued JWT, the calling service forwards the token (or trusted principal headers) to Darwan, and Darwan returns allow or deny with a reason. The two services are independent and can be deployed separately.

What is the API contract for /v1/authorize?

Authorize uses a split shape: action plus resourceType, not a flat permissionKey. A permission string such as sales.order.read is split on the last dot to action=read and resourceType=sales.order. The body also carries tenantId, principalId, optional resourceId, and subject/resource/context attribute bags for ABAC evaluation.

What workloads run on Darwan in production today?

Darwan is the authorization layer for the entire KaritKarma stack: BizRP (multi-tenant ERP), Aegis (anti-fraud), Hold.bd (cap table for banks), ISPChamp (ISP billing), BitsPath (communications), Boooks, Kuhok, Rating, Pressable, PlexBD, and others. Several Bangladesh banks evaluating BB Partner Network compliance also run dedicated Darwan tenants.

Get in touch

v1.authorize

Allow.
Deny.
Explain.

Name: Darwan
Brand: KaritKarma
Availability: InStock

Darwan is the authorization layer for every KaritKarma workload. One service decides who may do what, returns the rule that made the call, and signs the decision into an audit chain regulators can verify.

Request a tenant Read the API docs

REST endpoints

First-party SDKs

12+

Live tenants

POST /v1/authorize

HTTP / 200

Request

{
  "tenantId": "a5a73318-...",
  "principalId": "a2ca86be-...",
  "action": "read",
  "resourceType": "sales.order",
  "resourceId": "inv_8842"
}

Response

{
  "allowed": true,
  "decision": "allow",
  "reason": "rbac_allow",
  "matchedRule": "role:fulfilment_staff/sales.order.read",
  "policyVersion": "v17",
  "evaluatedInMs": 7
}

Live wire shape from production. Permission strings split on the last dot into action + resourceType. Every decision returns the matched rule and policy version.

A KaritKarma Product

/ Definition

What is Darwan?

Darwan is the authorization service for the KaritKarma platform. It answers one question on every request: may this principal perform this action on this resource inside this tenant?

Authentication is Wenme's job. Authorization is Darwan's. The decision is layered: a role grant is required first, then an ABAC policy overlay can deny the request based on attributes. Deny always overrides allow.

4 stages. Average evaluation: 7 to 14 ms.

01
Bind principal to tenant
Wenme issues the JWT, Darwan resolves principal-role assignments inside the tenant scope, then walks group-inherited roles. Expired time-bound assignments drop out before any rule fires.
02
RBAC grant required
The (action, resourceType) tuple is matched against the principal's effective role-permission set. No grant means deny. The check is pure-RBAC and is cached in Redis with a 60 to 120 second TTL.
03
ABAC policy overlay
Policy sets are versioned. Deny rules evaluate first, then allow rules with JSON conditions on subject, resource, and request context. Deny always overrides allow.
04
Explain + audit chain
Every decision returns the matched rule, the policy version, and the principal trace. The audit event is hashed into a SHA-256 integrity chain so tampering is detectable on review.

/ Compared

Where Darwan sits in the authorization landscape.

Most teams choosing an authorization service end up between Open Policy Agent, Casbin, Keycloak Authorization Services, or Okta FGA. Darwan is opinionated for SaaS-style multi-tenant workloads and Bangladesh Bank audit expectations. Side-by-side claims, attributed to the same evaluation question.

Claims about Darwan are from production source. Claims about other systems are paraphrased from each project's public documentation as of 2026.

Capability	Darwan	OPA	Casbin	Keycloak	Okta FGA
Multi-tenant by design	Every resource scoped by tenantId, isolation at the schema	Single-policy bundle, multi-tenancy is bring-your-own	Single enforcer, tenant routing in app code	Realm per tenant, separate admin surfaces	Per-org store, paid tier
RBAC plus ABAC overlay	RBAC grant required, then ABAC policy can deny	Pure ABAC, RBAC modelled on top	Model-string per pattern, no first-class layering	RBAC core, optional policy add-on	Roles plus expression-based policies
Explainable decisions	Matched rule, policy version, principal trace returned	Decision logs with input replay	Boolean only, no native trace	Token introspection, no per-decision trace	Policy decision logs in admin console
Signed audit chain	SHA-256 hash chain on every audit event	External SIEM responsibility	Adapter-dependent	Standard event log, no integrity chain	System log, retention via paid tier
Deployment model	Self-host or KaritKarma-managed in-region	Sidecar per service, you operate everything	Library, embedded in app process	Self-host, JVM operations	Hosted in US or EU regions only

Scroll horizontally on narrow viewports. Mobile collapses to Darwan-only column.

/ Who calls authorize

Darwan is the policy spine of the KaritKarma stack.

Every first-party product and several bank pilots route their allow/deny calls through Darwan. The same wire contract, the same audit chain, the same explainability surface, regardless of the calling service's language or runtime.

Several Bangladesh banks evaluating BB Partner Network Section 2.3.3 (RBAC) and 3.2.6 (audit immutability) run Darwan dedicated tenants under NDA. Public attributions are limited to KaritKarma products.

Wenme

Issues the OAuth 2.1 JWT Darwan validates

BizRP

Splits permission.key on the last dot, posts split shape

Aegis

Gateway middleware calls Darwan before any fraud rule fires

Hold.bd

Bank-facing cap table calls /v1/authorize per row

ISPChamp

Multi-tenant ISP billing scopes by Darwan principal-role

BitsPath

Communications platform gates send-as identities through Darwan

/ SDKs

First-party clients in the four runtimes that matter.

Every SDK speaks the split-shape contract natively, splits permission strings on the last dot, and ships with regression tests pinning the wire body. Custom languages can be generated from the OpenAPI document at /openapi/v1.json.

C# / .NET

First-party. Mirrors the .NET 10 server contract one-to-one.

sdks/darwan-dotnet

Split-shape client. Splits permission strings on the last dot before posting.

sdks/darwan-go

Node.js

OpenAPI-generated fetch client. Typed against /openapi/v1.json.

sdks/darwan-node

Rust

Tower-friendly client for high-throughput service-to-service auth.

sdks/darwan-rust

Observability surface

Built-in ASP.NET Core metrics pipeline, exported through whatever scraper you already run.

darwan_authorize_total
All authorize calls (allow + deny)
darwan_authorize_denied
Deny outcomes, broken down per reason
darwan_authorize_cache_hit
Redis cache hit ratio per tenant

Production substrate

Runtime: .NET 10
Store: PostgreSQL 18
Cache: Redis 7.4
Admin UI: Next.js
Auth model: Wenme JWT + dk_ keys
Audit: SHA-256 chain

/ Counter-positioning

What Darwan is, and what it deliberately is not.

Authorization has a long tradition of overreaching into identity, session, and audit territory. Darwan is small on purpose. Wenme owns identity, the calling service owns its session model, and the SIEM owns long-term retention. Darwan is the policy answer surface in between.

+Centralised allow/deny decision surface
+RBAC with optional ABAC overlay
+Per-tenant policy versioning
+Signed, queryable decision history
+Separation-of-duties (SoD) constraints with block or warn enforcement

Is not

−An identity provider. Wenme issues the JWT; Darwan validates and trusts it.
−A session store. The calling service owns session lifecycle.
−A SIEM. Audit events stream out for long-term retention elsewhere.
−A policy DSL playground. Policies are JSON conditions, not a new language to learn.
−Embedded in the calling service. Always a service call.

BB Partner Network

Darwan maps clause-by-clause to BB Partner Network sections 2.2.3, 2.3.3, 2.4.2.5, and 3.2.6.

Audit trails, authorised official access control, restricted remote privileged access, and role plus time-based access controls. Each clause is satisfied by a specific Darwan capability with a documented audit query that regulators can re-run.

Compliance mapping

/ FAQ

Questions buyers actually ask.

Mirrored verbatim in the FAQPage JSON-LD on this page so answer engines and bank IT departments can lift the responses cleanly.

What is Darwan?: Darwan is KaritKarma's centralised authorization service for regulated institutions. It answers a single question on every request: is this principal allowed to perform this action on this resource inside this tenant? Authentication is handled by Wenme (OAuth 2.1 with PKCE), and Darwan layers RBAC plus deny-override ABAC, explainable decisions, and a SHA-256 audit chain on top.
How does Darwan compare to Open Policy Agent?: OPA is a general policy engine deployed as a sidecar per service, with multi-tenancy and RBAC modelled in Rego by the application team. Darwan is opinionated for SaaS and regulated workloads: tenant isolation is first-class, RBAC and ABAC are layered with a deny-override rule, and a signed audit chain is built in. You operate one Darwan, not one OPA per service.
Does Darwan support attribute-based policies?: Yes. Policy sets are versioned, and each rule carries a JSON condition that runs against subject, resource, and request context. A typical use is restricting an invoice.read grant so a non-owner cannot read another department's invoice. Deny rules evaluate first, then allow rules. Deny always overrides allow.
Where does Darwan fit relative to Wenme?: Wenme answers who you are. Darwan answers what you may do. A request arrives with a Wenme-issued JWT, the calling service forwards the token (or trusted principal headers) to Darwan, and Darwan returns allow or deny with a reason. The two services are independent and can be deployed separately.
What is the API contract for /v1/authorize?: Authorize uses a split shape: action plus resourceType, not a flat permissionKey. A permission string such as sales.order.read is split on the last dot to action=read and resourceType=sales.order. The body also carries tenantId, principalId, optional resourceId, and subject/resource/context attribute bags for ABAC evaluation.
What workloads run on Darwan in production today?: Darwan is the authorization layer for the entire KaritKarma stack: BizRP (multi-tenant ERP), Aegis (anti-fraud), Hold.bd (cap table for banks), ISPChamp (ISP billing), BitsPath (communications), Boooks, Kuhok, Rating, Pressable, PlexBD, and others. Several Bangladesh banks evaluating BB Partner Network compliance also run dedicated Darwan tenants.

/ Provision

One service, one decision, one signature.

We provision a dedicated Darwan tenant, seed your role catalogue and permission registry, and hand back API keys for your runtime. The first allow/deny round-trip can land inside a week.

Request a tenant All KaritKarma products

Onboarding sequence

01Tenant provisioned, dk_ API key issued
02Permission registry seeded from your service catalogue
03Role templates loaded, assignments imported
04First /v1/authorize round-trip, audit chain live
05SoD rules enabled, access reviews scheduled

Allow.Deny.Explain.