I'm the cofounder/CTO of oso. Today we're opening oso up in Developer Preview and we're keen to hear your feedback.
In our earliest discussions building oso, we knew we wanted to build something to make it easier to add authorization to an application, but kept struggling with how to cleanly separate policies from an application while still retaining access to all the underlying classes, methods and data. The approach we landed on solves this problem by embedding oso as a library in the application and giving it direct access to all those things.
This is one of the problems we thought about when building oso, there are many more. oso is also written in Rust, which we think is a good choice for security software, and makes it possible to embed in different languages/environments. I'll stick around to answer any questions!
Sure, so one thing would be that CEL looks to be designed for writing expressions inside something else - like configuration files or other kinds of policies. So for example, its used within Firebase security policies, which are a superset of CEL. oso is a standalone policy engine that you add to your application as a library, and supports writing full policies made up of multiple rules and expressions.
Also, CEL is primarily based around protobufs as the core data objects, whereas we built oso to write policies directly over application objects in any language.
Otherwise, we definitely share a similar view on many parts of the language design.
Question. Could I use this to store all my authorization tokens across a suite of apps used within a given identity management suite (let's say I have SSO with Okta for apps in GSuite, Jira, etc.)?
oso could use tokens stored in another system from within your policy to make authorization decisions. However, it isn't a secrets management tool, so we wouldn't recommend using it to store authorization tokens for the same reason you wouldn't store them in your codebase.
1) In the near future: JavaScript/TypeScript (via Web Assembly), Go, Rust. Longer term, many more!
2) Absolutely! You could use it to extend your existing authorization code or slowly replace the existing code piece-by-piece or use oso for all authZ on a greenfield project.
Right now the idea is you would treat policy files like source code. So any changes should go through CI/CD to be pushed out to production. Any dynamic data can be managed directly through the application, and easily referenced in the policy itself.
Polar is inspired by Prolog, a logic programming language, and designed to express authorization policies in a declarative style. One of the main things we wanted was a language that embeds well so that Polar can use types from your application and call functions & methods directly. We wrote up some of the design principles here [1], and a (warning: pretty detailed) background on the language here[2]
- It's an ideal language for writing security-focused software given that it eliminates memory safety bugs (a leading cause of security vulnerabilities in the wild).
- Authorization is generally on the critical path, so providing a decision quickly is very important. Rust is extremely fast, but more crucially it doesn't have runtime garbage collection so there's no possibility of an ill-timed GC run disrupting your application.
- Rust has a great language interoperability story. We designed oso as a library that you embed in your application. The upshot of that is that we've already built Java, Python, and Ruby libraries, with additional languages to follow. Using Rust allowed us to write the core logic and runtime once in a correct, extremely performant language and then write the language libraries as thin shells around the Rust core. That lowered the bar for expanding oso to new languages pretty dramatically.
In our earliest discussions building oso, we knew we wanted to build something to make it easier to add authorization to an application, but kept struggling with how to cleanly separate policies from an application while still retaining access to all the underlying classes, methods and data. The approach we landed on solves this problem by embedding oso as a library in the application and giving it direct access to all those things.
This is one of the problems we thought about when building oso, there are many more. oso is also written in Rust, which we think is a good choice for security software, and makes it possible to embed in different languages/environments. I'll stick around to answer any questions!