
Show HN: oso – Open-Source Policy Engine for Authorization - samjs
https://www.osohq.com/
======
samjs
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!

------
mleonard
Interesting! Congrats on the launch.

Would you mind comparing it to Google's CEL?
[https://opensource.google/projects/cel](https://opensource.google/projects/cel)

~~~
samjs
Thank you!

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.

------
francesca
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.)?

~~~
samjs
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.

------
hneray
Cool

2 questions: 1) Languages you plan to support? 2) Does it require a rip and
replace, or can oso be implemented incrementally?

~~~
samjs
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.

------
Toidiu
Congrats!

I was wondering what is the mechanism for updating/invalidating a policy file
across a fleet of servers?

~~~
samjs
Thanks :)

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.

------
gringao
Hey team, looks really cool. What was the inspiration behind the policy
language you built?

~~~
samjs
Thanks :)

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]

[1] [https://docs.osohq.com/more/design-
principles.html](https://docs.osohq.com/more/design-principles.html)

[2] [https://docs.osohq.com/more/language/polar-
foundations.html](https://docs.osohq.com/more/language/polar-foundations.html)

------
meghan
Cool - congrats! Would love to hear more about why you chose Rust for this?

~~~
samjs
Thank you! We chose Rust for a few main reasons:

\- 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.

------
c_s_j
This is awesome, congrats to the whole team!

------
erlichson
Congrats on the launch :-)

~~~
samjs
Thanks!

