8 ms·

Oso – open-source policy engine for authorization in Rust

98 points by dragonsh 6y ago

royjacobs 6y ago
This is quite interesting, although I'm worried about the policies being tied to the underlying programming language. While this does allow for additional flexibility, it makes them hard to share in a polyglot shop.
- victor106 6y ago
  I agree it looks really nice. But are there any policy engines that allow you to express policies in a language neutral way?
  - royjacobs 6y ago
    I believe that's the main selling point of OPA (as also pointed out by the_duke in the other comment).
- the_duke 6y ago
  I've used OPA [1] before, which is very similar. The whole point is to have language agnostic policy definitions. You write policies in the custom policy language, and every application that needs to do permission checks goes through the provided policy engine. The programming language specific code just is some plumbing for accessing the policy agent. So policies are inherently shareable. [1] https://www.openpolicyagent.org/ https://www.openpolicyagent.org/
  - samjs 6y ago
    (oso CTO, somewhat biased) > The programming language specific code just is some plumbing for accessing the policy agent. If you want to make policy decisions over your application data you still need to work out a way to move it into the OPA service, or send it as part of the policy request. You can make oso policies language agnostic if you take a similar approach and have a small number of shim rules that handle the application-specific parts.
  - samjs 6y ago
    I will say though: OPA is an awesome project and we drew a bunch of inspiration from it early on. I'm excited about more people being aware of the power of declarative policy as code :)
- samjs 6y ago
  Hey! oso cofounder/CTO here. You're right, and this is something we've discussed a bunch. Our current view is that: 1. Allowing teams to standarise on an _approach_ and a library in the first place is a huge step up from individual ad hoc implementations. 2. If you have shared logic between applications, you can still write language-agnostic policies and share those between them. If there are parts that are specific to an application/language, its easy enough to pull these into separate rules and add shims. 3. We intentionally wanted to keep the language lean to lower the learning curve. But we're considering adding a standard library in the future, powered by the Rust core, to provide common functionality. The nice thing is that you're not limited by how fast we add those. We're interested in hearing from folks who are working in those environments to hear what would make the most sense for them.
- deleted 6y ago
  [deleted]
denysvitali 6y ago
What's the main advantage over OPA?
- strmpnk 6y ago
  I looks like it’s written in Rust which isn’t super special but would be far easier to embed as a library in other languages compared to Go in OPA’s case. Polar also seems like a nicer policy language (strong Prolog vibes) though this is subjective as I’ve not done a deep comparison yet.
  - samjs 6y ago
    Yep, you're right on this one! We went with Rust because we wanted to make it embeddable in other languages. And on the policy language. Polar is indeed a prolog variant. You can see pretty early we took the decision to diverge from a more familiar prolog syntax [1] because we wanted to make it a little more accessible. 1: https://docs.osohq.com/changelogs/0.2.0.html https://docs.osohq.com/changelogs/0.2.0.html
- samjs 6y ago
  Hey denysvitali. oso CTO here. oso was designed to be embedded directly in applications as a library. So there's no additional service to run to use it to make authorization decisions in an application. The other part is that oso policies are written directly over your application data - e.g. the classes/types, and can access attributes and call methods. There's no integration work needed to get application data available to the policy to start making decisions, nothing to keep in sync, and no additional network overhead.
  - charlieegan3 6y ago
    Would you consider something comparable to an OPA server as a future possibility for oso? I think that’s something that’s really valuable about OPA in a microservices environment - having a single place to consult for and log policy decisions. I suppose I could implement an OSO server to perform this function. I’d also be interested to know if you’d compared the performance of oso policy vs Rego on comparable input.
samjs 6y ago
Hey all! I'm Sam, CTO at oso. Thanks to OP for posting this. A very pleasant surprise to wake up and find this here :) I'll be around to answer any questions people have, but you can also find myself and the team in our community slack: https://join-slack.osohq.com/ https://join-slack.osohq.com/ All the docs are hosted here: https://docs.osohq.com/ https://docs.osohq.com/ And we have written up various articles on using oso and some of the internals on our blog: https://www.osohq.com/company/blog https://www.osohq.com/company/blog
- OJFord 6y ago
  What are you going to charge for?
  - charlieegan3 6y ago
    It looks like they charge for support. https://www.osohq.com/developers/support https://www.osohq.com/developers/support
    - gneray 6y ago
      This is true. But truth be told, if you reach out to us via Slack/email/whatever we will do our best to help you regardless. Every eng on the team takes part in our community support rotation. We typically respond to a new Slack message in <5 min during business hours, and we watch it closely and respond as quickly as possible outside of that. We are eager to help our users. The commercial support options are for customers that require specific contractual SLAs, etc.
  - gneray 6y ago
    The core for developers will continue to be free and open source – i.e., libraries, language + policy engine, debugger, REPL. We’ll have a commercial product geared towards ops and security teams. We’re not yet ready to take the wraps off anything yet, but among the things we’re working on or planning: an oso mgt, service, auditing, policy governance, etc. See also: https://news.ycombinator.com/item?id=25443747 https://news.ycombinator.com/item?id=25443747
kache_ 6y ago
There is a serious gap in the market for attribute based authorization.
- gneray 6y ago
  Agreed (other oso cofounder here). Would even be great to move beyond terms like attributed-based access control (ABAC), which many devs aren't familiar with even if they've actually built those features (e.g., a user can read her own data). ABAC is technically so broad, when in reality it's the underlying patterns that matter, e.g., hierarchies, sharing, multi-tenancy...many more.
lock-free 6y ago
I'd like to buy into Rust for authentication, but the compile times cost too much money and I wound up purging it. This library needs a lot of work to speed up compile times before I can use it. Procedural macros are usually opt-in through cargo features because of their extreme hits to compile time (this includes stuff like serde), and if you're trying to monetize this I'd recommend having precompiled binaries available somewhere so I don't need to pull things from crates.io to compile it cold. I timed it on a laptop that I know to have similar power to a CI runner. This is after `cargo build`: real 5m16.508s user 10m41.961s sys 0m44.432s
- samjs 6y ago
  Hey! oso CTO here. Thanks for giving it a try! Were you using this in a Rust project, or building it from scratch for some other language? For the latter, we do provide libraries for Python, Ruby, Java, Nodejs with the Rust core precompiled. It's a tricky CI challenge for us, but shouldn't affect users. If you're using in a Rust project, then you will indeed need to pull in our dependencies. Though we are pretty lean on dependencies, and I would expect most projects using oso would be using serde anyway. That being said those times you're seeing seem very long, even for Rust! Is that building with `--release`? Also, the time to compile it the first time will be slow, esp. including downloading the source. But incremental builds are a lot faster. We do a little caching in CI to make this a bit less painful.
  - lock-free 6y ago
    I was just checking the build times from your github repo by running cargo build. If I used it in a project it would be multi-language and require linking against native code through a C shim. It would be great if that was provided and had a stable ABI + .so for the rust code that I could install through a .deb or .rpm instead of building through cargo. > Though we are pretty lean on dependencies, and I would expect most projects using oso would be using serde anyway. It would be great if `serde` was opt-in through cargo features, which is pretty common in the Rust ecosystem. While your manifests are small there's still quite a bit getting pulled in. Might want to inspect the dependency graph to see if there's anything excessive or some features that can be non-defaulted. > That being said those times you're seeing seem very long, even for Rust! Not in my experience. This was a clean debug build. It's not that uncommon on CI runners to have much longer times than developer machines (MacOS CI runners are especially bad about this, and also cost a lot more money). That's why I do profiling on a weaker one when evaluating build times. Incremental builds are faster, they're also harder to orchestrate. Not trying to be overly critical, just trying to give a view! Compiling on other people's machines is expensive, a good way for me to buy into something like this instead of doing it myself (which is how I'm doing it right now!) is to reduce the dependency tree and make building stupid fast/easy.
roguepandaz 6y ago
Rongxin here! This is freaking awesome to see how far it's progressed.
- samjs 6y ago
  Hey Rongxin! Thanks :) It's been a fun ride. I'm going to drop you a message, it's been far too long...
adolph 6y ago
The recent TalkPython podcast "oso authorizes Python" is great for understanding what oso does, how it goes about it, and how oso's role is different from identity providers. https://talkpython.fm/episodes/show/294/oso-authorizes-python https://talkpython.fm/episodes/show/294/oso-authorizes-pytho...

98 points by dragonsh 6y ago

This is quite interesting, although I'm worried about the policies being tied to the underlying programming language. While this does allow for additional flexibility, it makes them hard to share in a polyglot shop.

victor106 6y ago
I agree it looks really nice. But are there any policy engines that allow you to express policies in a language neutral way?
- royjacobs 6y ago
  I believe that's the main selling point of OPA (as also pointed out by the_duke in the other comment).
the_duke 6y ago
I've used OPA [1] before, which is very similar. The whole point is to have language agnostic policy definitions. You write policies in the custom policy language, and every application that needs to do permission checks goes through the provided policy engine. The programming language specific code just is some plumbing for accessing the policy agent. So policies are inherently shareable. [1] https://www.openpolicyagent.org/ https://www.openpolicyagent.org/
- samjs 6y ago
  (oso CTO, somewhat biased) > The programming language specific code just is some plumbing for accessing the policy agent. If you want to make policy decisions over your application data you still need to work out a way to move it into the OPA service, or send it as part of the policy request. You can make oso policies language agnostic if you take a similar approach and have a small number of shim rules that handle the application-specific parts.
- samjs 6y ago
  I will say though: OPA is an awesome project and we drew a bunch of inspiration from it early on. I'm excited about more people being aware of the power of declarative policy as code :)
samjs 6y ago
Hey! oso cofounder/CTO here. You're right, and this is something we've discussed a bunch. Our current view is that: 1. Allowing teams to standarise on an _approach_ and a library in the first place is a huge step up from individual ad hoc implementations. 2. If you have shared logic between applications, you can still write language-agnostic policies and share those between them. If there are parts that are specific to an application/language, its easy enough to pull these into separate rules and add shims. 3. We intentionally wanted to keep the language lean to lower the learning curve. But we're considering adding a standard library in the future, powered by the Rust core, to provide common functionality. The nice thing is that you're not limited by how fast we add those. We're interested in hearing from folks who are working in those environments to hear what would make the most sense for them.
deleted 6y ago
[deleted]

denysvitali 6y ago

What's the main advantage over OPA?

strmpnk 6y ago
I looks like it’s written in Rust which isn’t super special but would be far easier to embed as a library in other languages compared to Go in OPA’s case. Polar also seems like a nicer policy language (strong Prolog vibes) though this is subjective as I’ve not done a deep comparison yet.
- samjs 6y ago
  Yep, you're right on this one! We went with Rust because we wanted to make it embeddable in other languages. And on the policy language. Polar is indeed a prolog variant. You can see pretty early we took the decision to diverge from a more familiar prolog syntax [1] because we wanted to make it a little more accessible. 1: https://docs.osohq.com/changelogs/0.2.0.html https://docs.osohq.com/changelogs/0.2.0.html
samjs 6y ago
Hey denysvitali. oso CTO here. oso was designed to be embedded directly in applications as a library. So there's no additional service to run to use it to make authorization decisions in an application. The other part is that oso policies are written directly over your application data - e.g. the classes/types, and can access attributes and call methods. There's no integration work needed to get application data available to the policy to start making decisions, nothing to keep in sync, and no additional network overhead.
- charlieegan3 6y ago
  Would you consider something comparable to an OPA server as a future possibility for oso? I think that’s something that’s really valuable about OPA in a microservices environment - having a single place to consult for and log policy decisions. I suppose I could implement an OSO server to perform this function. I’d also be interested to know if you’d compared the performance of oso policy vs Rego on comparable input.

samjs 6y ago

Hey all! I'm Sam, CTO at oso. Thanks to OP for posting this. A very pleasant surprise to wake up and find this here :) I'll be around to answer any questions people have, but you can also find myself and the team in our community slack: https://join-slack.osohq.com/ https://join-slack.osohq.com/ All the docs are hosted here: https://docs.osohq.com/ https://docs.osohq.com/ And we have written up various articles on using oso and some of the internals on our blog: https://www.osohq.com/company/blog https://www.osohq.com/company/blog

OJFord 6y ago
What are you going to charge for?
- charlieegan3 6y ago
  It looks like they charge for support. https://www.osohq.com/developers/support https://www.osohq.com/developers/support
  - gneray 6y ago
    This is true. But truth be told, if you reach out to us via Slack/email/whatever we will do our best to help you regardless. Every eng on the team takes part in our community support rotation. We typically respond to a new Slack message in <5 min during business hours, and we watch it closely and respond as quickly as possible outside of that. We are eager to help our users. The commercial support options are for customers that require specific contractual SLAs, etc.
- gneray 6y ago
  The core for developers will continue to be free and open source – i.e., libraries, language + policy engine, debugger, REPL. We’ll have a commercial product geared towards ops and security teams. We’re not yet ready to take the wraps off anything yet, but among the things we’re working on or planning: an oso mgt, service, auditing, policy governance, etc. See also: https://news.ycombinator.com/item?id=25443747 https://news.ycombinator.com/item?id=25443747

kache_ 6y ago

There is a serious gap in the market for attribute based authorization.

gneray 6y ago
Agreed (other oso cofounder here). Would even be great to move beyond terms like attributed-based access control (ABAC), which many devs aren't familiar with even if they've actually built those features (e.g., a user can read her own data). ABAC is technically so broad, when in reality it's the underlying patterns that matter, e.g., hierarchies, sharing, multi-tenancy...many more.

lock-free 6y ago

I'd like to buy into Rust for authentication, but the compile times cost too much money and I wound up purging it. This library needs a lot of work to speed up compile times before I can use it. Procedural macros are usually opt-in through cargo features because of their extreme hits to compile time (this includes stuff like serde), and if you're trying to monetize this I'd recommend having precompiled binaries available somewhere so I don't need to pull things from crates.io to compile it cold. I timed it on a laptop that I know to have similar power to a CI runner. This is after `cargo build`: real 5m16.508s user 10m41.961s sys 0m44.432s

samjs 6y ago
Hey! oso CTO here. Thanks for giving it a try! Were you using this in a Rust project, or building it from scratch for some other language? For the latter, we do provide libraries for Python, Ruby, Java, Nodejs with the Rust core precompiled. It's a tricky CI challenge for us, but shouldn't affect users. If you're using in a Rust project, then you will indeed need to pull in our dependencies. Though we are pretty lean on dependencies, and I would expect most projects using oso would be using serde anyway. That being said those times you're seeing seem very long, even for Rust! Is that building with `--release`? Also, the time to compile it the first time will be slow, esp. including downloading the source. But incremental builds are a lot faster. We do a little caching in CI to make this a bit less painful.
- lock-free 6y ago
  I was just checking the build times from your github repo by running cargo build. If I used it in a project it would be multi-language and require linking against native code through a C shim. It would be great if that was provided and had a stable ABI + .so for the rust code that I could install through a .deb or .rpm instead of building through cargo. > Though we are pretty lean on dependencies, and I would expect most projects using oso would be using serde anyway. It would be great if `serde` was opt-in through cargo features, which is pretty common in the Rust ecosystem. While your manifests are small there's still quite a bit getting pulled in. Might want to inspect the dependency graph to see if there's anything excessive or some features that can be non-defaulted. > That being said those times you're seeing seem very long, even for Rust! Not in my experience. This was a clean debug build. It's not that uncommon on CI runners to have much longer times than developer machines (MacOS CI runners are especially bad about this, and also cost a lot more money). That's why I do profiling on a weaker one when evaluating build times. Incremental builds are faster, they're also harder to orchestrate. Not trying to be overly critical, just trying to give a view! Compiling on other people's machines is expensive, a good way for me to buy into something like this instead of doing it myself (which is how I'm doing it right now!) is to reduce the dependency tree and make building stupid fast/easy.

roguepandaz 6y ago

Rongxin here! This is freaking awesome to see how far it's progressed.

samjs 6y ago
Hey Rongxin! Thanks :) It's been a fun ride. I'm going to drop you a message, it's been far too long...

adolph 6y ago

The recent TalkPython podcast "oso authorizes Python" is great for understanding what oso does, how it goes about it, and how oso's role is different from identity providers. https://talkpython.fm/episodes/show/294/oso-authorizes-python https://talkpython.fm/episodes/show/294/oso-authorizes-pytho...