Tiny Ltd completed its acquisition of Oso Cloud on October 1, 2026, and most of the Oso team is joining Temporal. Oso says Oso Cloud will keep operating as usual. If your production authorization runs on it, this is still a good moment to write down what your Polar policies actually do, while you have working knowledge of them.
Most Polar files mix three patterns. Sorting them first makes any target easier to pick:
- Role grants inside a resource block, like
"push" if "admin";. This is plain RBAC: a resource, its actions, and roles that hold permissions. - Role derivation through a relation, like
"reader" if "member" on "organization";. In ReBAC terms you need the relation defined on the resource type, plus the actual relationship data (repo-1 belongs to org acme) synced from your app. - Attribute conditions in
allowrules, such asuser.department == "engineering" and doc.classification != "restricted". Those attributes either get synced ahead of time or passed in with each check.
The call site changes least. oso.authorize(user, "read", document) becomes one check with user, action and resource, plus a tenant if you're multi-tenant. List filtering and "which resources can this user see" queries need their own mapping, so inventory those endpoints early.
One more thing to look for: the open-source Oso library (the standalone Polar engine) was deprecated in December 2023, in case an older service still depends on it.
Disclosure: I work at Permit.io. My colleague Ze'ev Manilovich wrote the full guide, with Permit SDK examples for each pattern and a step-by-step migration plan:
Top comments (1)
Great breakdown! Mapping Polar policies to RBAC, ReBAC, and ABAC before migrating is a smart approach. Auditing relationship data, attribute handling, and resource-level filtering early can help avoid authorization gaps during the transition. Thanks for sharing these practical insights!