DEV Community

Auth By Example
Auth By Example

Posted on

Sorting your Polar policies before you pick an Oso alternative

I am on the marketing team at Permit. A lot of teams are re-reading their Oso setup this month, and sorting the Polar policies tends to get skipped at the start.

Oso Cloud was acquired by Tiny, with the deal closing on Oct 1, and Oso says Cloud will continue to operate as usual. Most of the Oso team joined Temporal. Nothing in that announcement means a team has to move today.

If you are planning a move, export your Polar policies first and sort each rule before you evaluate vendors. Role grants inside a resource block are RBAC. A role that comes from a relation is ReBAC, for example a repo reader who inherits from an org member, and copying that rule across also means syncing the relationship data behind it. Conditions on user or resource attributes are ABAC. For those you need to decide whether the attributes get synced ahead of time or sent with each check.

List filtering deserves its own line in the inventory. A single check and a query for every document a user can read do not fail in the same way.

We published a longer mapping with Permit code examples for each pattern: https://www.permit.io/blog/migrate-from-oso-to-permit?utm_source=devto&utm_medium=social&utm_campaign=oso-migration

Whatever target you pick, run the old and new systems side by side for a while and log where they disagree. Cut over after the disagreements reach zero.

Top comments (0)