Oso Success Stories!

[saolsen]

This issue is to collect Oso success stories!

Success stories help us to see what features of oso are the most useful and help other users to see examples of different problems Oso has solved and understand how it can work for them. If you have a story to share please comment below!

How have you used Oso? Did you use it to replace something more complicated or get something off the ground faster? What is your favorite thing about Oso? How has Oso helped you?

[snmishra]

We, WayLit, are still very early on Oso adoption. We're using it with our Django web app.

Before Oso we were using django-guardian for object-level permissions. django-guardian is quite nice and mature. However, the authorization rules were in several places and it was hard to understand when things were wrong. We'd often have users unable to access stuff they should be authorized to access.

With Oso all those rules are in one place and we can review them quickly. So far we are using RBAC only.

We might end up adding some ABAC to allow one-time access or exceptions to the RBAC rules.

[harleylang]

I've been using oso for ~10 months, first with python and currently via node. It has been a fabulous experience.

Right now oso sits on (almost) every api route of the ed-tech web app I am building over at Intraverbal.com. Just a moment ago I ran my test suite for my oso policies. I'm closing in at almost 700 tests covering ~370 lines of polar policy (probably much less than that when blank lines are removed). All tests are passing, as they always do. I have seen tests fail only as a result of my error when writing new policies, that's it. The library is super reliable.

I'm aiming to open Intraverbal to the public this Fall, and I'm hoping to have some production data to share with those interested at that time. Until then, the oso team has published two blog posts about my experience with oso that can be found here:

• Intraverbal Use Case - Includes example policies.
• Community Hackathon - You can find my project hello-polar here.

If you're on the fence about integrating oso, know that you are in good hands. I've had the chance to get to know the team. They are smart, generous, compassionate people who will help you write effective authorization code.

[kc-fiddler]

We adopted Oso as a way to retrofit access control to our existing product. The documentation, examples and the support provided on the slack channels is just plain awesome..

My previous experience with all things RBAC/ABAC in some of my previous roles was something like changing the base constructs for adding such abstractions and plumbing the various layers to facilitate the checks and filtering. It was not for the light of heart.. :smile:

Oso has abstracted a lot of that complexity away into 1 polar file and we have ingress-nginx and/or envoyproxy call into Oso for authz.

I'm glad I found Oso when I did.. :pray:

[ximon18]

Around the middle of last year we released a new v0.9.0 version of our Rust powered Krill product that replaced the existing limited authz code with a much richer and user extensible model powered by Oso v0.12.4.

Using Oso we added an RBAC / ABAC permission model to the product at the REST API level and also in a couple of places deeper in the application logic. At the same time separately to, but in combination with Oso, we added OpenID Connect capability and can assign Oso roles to users based on their OpenID Connect metadata and allow OpenID Connect metadata to be used by policy rules. We provided a few built-in roles which encapsulate subsets of certain internal permissions, e.g. admin, read-write, read-only, but we also made it possible for users to provide their own Polar files to extend the policy logic for things like team based access control or access to subsets of application resources.

Since our work using Oso we haven't had to go back to it and we haven't had any issues raised thus far. If we did go back to it we'd probably look at using some of the functionality added to Oso since as Oso gained richer RBAC support around the time we were integrating it and since then also gained higher level policy syntax support and lots more I'm sure.

I won't say learning the Oso policy language Polar was easy, but then thanks to the documentation that has only continued to get better and the frankly amazing support and rapid turn around time on bug fixes it also wasn't hard and using Oso was a joy.

For more information about what we did check out the end-user docs and also some developer facing docs that we added at the time, our Oso policy files and some additional examples and of course the Rust application code.