The Python Podcast.__init__

Share on social media:

[00:00:14] Unknown:

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.   When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode.   With the launch of their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,   including simple pricing, node balancers,   40 gigabit networking,   dedicated CPU and GPU instances, and worldwide data centers.  

Go to python podcast.com/linode,   that's l I n o d e, today and get a $100 credit to try out a Kubernetes cluster of your own. And don't forget to thank them for their continued support of this show.   Are you bored with writing scripts to move data into SaaS tools like Salesforce, Marketo, or Facebook Ads? Hightouch is the easiest way to sync data into the platforms that your business teams rely on.   The data you're looking for is already in your data warehouse and BI tools. Connect your warehouse to Hightouch, paste a SQL query, and use their visual mapper to specify how data should appear in your SaaS systems.   No more scripts, just SQL. Supercharge your business teams with customer data using Hightouch for reverse ETL today. Get started for free at python podcast.com/hitouch.  

Your host as usual is Tobias Macy. And today, I'm interviewing Sam Scott about Oso, an open source library for managing authorization in your applications. So, Sam, can you start by introducing yourself? My name is Sam. I'm the cofounder and CTO at Oso. We're a startup primarily based in New York, just under 10 people,  

[00:01:47] Unknown:

but growing rapidly.  

[00:01:49] Unknown:

And do you remember how you first got introduced to Python?  

[00:01:51] Unknown:

I do. So   I was originally a mathematician by training. I got introduced to Python specifically   as part of, like, a number theory course where we used a maths package called called Sage.   So I had 1 of my lecturers who was, like, a contributor to it and and kinda used that as part of the lectures around doing some number theoretical stuff.   And   yeah. I loved it. It was great.   Can you start by giving a bit of a description about what the Oso project is and some of the story behind how it got started? Yeah. Sure. So as I kinda said at the beginning, Oso is a startup I'm cofounder of. The origins of Oso kinda go back almost 3 years now. My cofounder and Graham and I, we we sort of got together around this idea, this vision of making security more accessible for developers.   That was kind of the original core idea of of of what we wanted to build,   and what we're what we're building for that today is   this open source library called Oso, which is for building authorizations to your apps. The the reason we got on to authorization specifically,   we went out and spoke to, you know, hundreds of different   teams, engineers, security people, developers, product managers, all kinds, you know, asking really around what they were struggling with with security.  

Originally, we were trying to build stuff in the infrastructure space, but we kept on hearing,   yeah. Yeah. Yeah. That stuff's important, but, you know, I'm I just spent, you know, 6 months trying to build roles in my application. Like, does your thing solve that?   1st few times, we're like, no. No. No. No. We're we're on the infrastructure side of things. We don't do that. And, eventually, we sort of realized we should maybe listen to what people are telling us is the problem and not trying to tell them.  

[00:03:18] Unknown:

Yeah. It's security and authorization and access control are definitely all complex problems and difficult to manage. And there have been   countless attempts at doing it, quote, unquote, the right way or sort of the 1 true way. So,   you know, as you mentioned, you had this idea of it was going to be infrastructure oriented, but developers were saying, no. I'm just struggling with getting it to work on my application at all. So   I'm curious as you started to dig more into the application and software side of   things, what was your kind of assessment of the current state of the ecosystem   in Python or in other programming languages for being able to actually   design and enforce   usable policies and authorization   and access controls. And what was missing in terms of the capabilities either built into the languages and frameworks or just overall sort of libraries and the   ergonomics and design of these systems?  



[00:04:13] Unknown:

There's so many pieces to this. So I think, you know, every,   I would say, you know, web framework or application framework in general, there's often   usually not built into the framework itself, but there's usually, you know, number of packages or libraries that let you do some amount of authorization as as part of that, and it's maybe better or worse integration to your into the overall ecosystem.   The limitation with those often tends to be that they try and enforce us kind of a single model on you. You know, maybe they provide something like roles, which we I'm sure we'll end up speaking about later. They give you maybe, like, 1 pattern.   But   the thing with authorization, which which is really interesting, is it's so different for every application. And, like, most people we spoke to is a lot of people we speak to, they're like,   I'm not sure you could even solve authorization for us generically. We have this really unique situation where we need to give access to blah and blah based on this and this and this and this. So   often a lot of people end up not using, like, libraries or frameworks and just trying to build it into their app themselves. This, you know, becomes, you know, spaghetti code of if statements, like, sprinkled throughout the app just doing all these, like, small pieces of custom logic.  

The authorization logic is both, like, both very deeply coupled with your application, your application data, the things that people can do in your app. It is, like, highly highly different based on the application. So   that was kind of the tension we were seeing is that there's, you know, existing libraries that feel maybe too restrictive.   So instead, most people are just kinda, like, going full ad hoc, build it themselves,   you know, refactoring   multiple times a year, you know, spending months months months each time being like, oh, we need this thing and and kind of reinventing it. We set out to address that problem.   The original thing we wanted to do was build something that was, like, powerful and flexible enough that could solve,   like, the whole spectrum of, like, authorization problems.  

I guess we'll come back to that piece later. You know, that's where the sort of policy engine comes from, allow you to kinda represent anything.   But as we started doing that, we then started realizing that there's actually   maybe 80% of everybody's applications, like, build on the same concepts. And this is kind of coming back to those, like, libraries and frameworks who didn't have it so wrong in the first place. It's like, actually, most people do have, like, 80% the same thing. It's, you know, roles plus some custom logic.   Now we've, like, covered the wide spectrum, we're kinda now coming back and adding, like, tons of extra structure on top. So you kinda get that best of both worlds. It's like, if you do need the same pattern that most other people have, you kinda get that out of the box. But then you still have that kind of, like, last 20%.  



[00:06:29] Unknown:

You know, everyone knows the 80 20 rule. You know, the last 20%, you can still customize to your heart's content. As far as the kind of out of the box experience, is that encapsulated with those integrations that you've built for Django and SQLAlchemy and Flask that I saw when I was digging through your documentation?  

[00:06:43] Unknown:

Yeah. That's exactly right. Although, we have   probably the most   I'm not sure when this will go out, but we have, like, probably some of the more exciting stuff of this area coming out, you know, within the next month or so. I think there's even more we can do. So for example, the experience we want you to have, it's like you maybe know that you need, like, roles that are back in your app, and we just basically wanna give you sort of almost like 1 line of code that allows you to add that in your app and kinda continue moving forwards. And so we've got the beginnings of that in SQL alchemy,   but there's a lot more we wanna do there. In terms of the  

[00:07:14] Unknown:

foot guns that developers run into as they're trying to build out their own access control and authorization   policies or if they're maybe   using a library or framework that's going to kind of help them aim that foot gun a little bit higher. You know, what are some of   the missteps that they still might run into or some of the common mistakes that that you've seen as far as how to   integrate this authorization logic  

[00:07:40] Unknown:

within an application and maybe some of the types of technical debt that can be accrued as a result? I'd say there's 2 sides of this. I think 1 is the end user facing part of this, which I think is a hugely important part of authorization. And the other, as you mentioned, is kinda like the internal technical debt part of this. So I think on the user facing side,   the thing that can be tempting is to   be very responsive to   what your customers are asking you for and, like, adding new roles and new permissions and new ways to customize the, like, access control model to your heart's content. And then actually, like, creating a situation where   people can break the app because they misconfigured something and need to explain on a   if you set up it this way, you can't set this configuration and so on and so on. Like, that logic starts kinda being pushed towards the user to understand.  

And, you know, sometimes you get those, like, giant pages, matrices of, like, permissions that he's trying to understand before you can work out how to use the app. I think that's, like, 1 of the biggest ones for me and, like, the the user facing side of things from, like, the products is making your authorization so complex that it takes people ages to understand it.   I think, internally,   data models are such a hugely important piece of of authorization,   and I've spoken about roles a lot. You know, roles is, in theory, is a very simple model. It's, like, kind of a main to main relationship   between, say, like, a user and an organization.  

In in that way, a user can have a role in in an org.   Those kind of things often start out very simple where someone might think, I just need, like, an admin field. You know, a user can be an admin or not. You know, that's a Boolean field.   But then when they realize they need multiple roles, they refactor that and it becomes a string field. And then they realize they need the ability to have multiple roles in different organizations if you're building something like, you know, GitHub with collaboration or you need,   you know, roles which don't just apply to to organizations.  

They also apply to, you know, projects or folders or something like that. And you go through these, like, refactoring cycles of moving from, like, 1 to many to many to many to, like, multiple tables, and each 1 can be pretty hard to do right. So that's, like, 1 of the big things that we try to address, not just in Oso, but more generally in the information we provide. We have this series of guides called authorization academy  

[00:09:41] Unknown:

that basically walks you through what you need to do to build authorization to your app, not from an ISO perspective, but just, like, more broadly. So we talk through, like, here's the roles model that you can use that will, like, allow you to go from, like, where you are today to, you know, the next 4 iterations. You know, skip that process and just start start on the right model at the beginning. Yeah. And even with sort of quote unquote simple role based access control, there's the complexity of, okay, well, what happens if this person has 2 different roles, and now I need to have a hybrid role? And, you know, you think I just need 3 different roles because we have, you know, admins, managers, and users, and then, well, okay, what if a user also needs to be able to administer things for other people on their team? So Oh, exactly. Exactly. Of never ending kind of fractal   of complexity.  



[00:10:26] Unknown:

Yeah. That's right.  

[00:10:27] Unknown:

And as far as Oso itself,   so from the 30, 000 foot view, what's actually   involved in getting it added into a piece of software and the kind of main types of applications that you're focusing on integrating Oso with? The main kinds of applications we're focusing on, I would say, is your typical  

[00:10:47] Unknown:

business to business, b to b, SaaS application.   Those are the ones we typically need some amount of   authorization from the beginning, you know, at the very least, giving people access to different organizations   and having roles and and things like that within that. So that kind of an app, right, the process is, like, pretty straightforward. There's you   install also from your favorite package manager, you know, it's pip install also for Python land.   You pretty much, you know, you create an instance of your of the Oso objects,   and you're basically now ready to start making these, like, is allowed calls. Is this, like, 1 interface you have to   decide if something is authorized or not? That's kind of it. And it's like, alright. That's your, like, blank slate. I now have this, like, ability to do authorization.  

And now the way you can actually now start, like, implementing your logic, like, deciding who could do what is through the policy language called polar. So this is a language we built. It's like a declarative, logic based language specifically for authorization   that allows you to kind of express who can do what with with, like, a number of rules. And this is kinda, like, what powers that, like, authorization logic of, like, making these decisions.   And then, you know, when I talk about some of the stuff around, like, you know, out of the box support for things like roles,   those are effectively, like, you know, libraries provided for polar that will just, you know, take away all of that work from how you have to model the roles that will help you do the data modeling, things like that. How much time did you spend in the early design phases figuring out how to make YAML work for that?  

How did you know?   We started with Jason, actually, but,   it's funny. V 1 of this, purely in Python,   That was our original, like, POC.   Very, very   Python class driven.   We found that it basically looked like a DSL in itself because you had to, like, understand all these random classes to understand how to use it. We did try and do some stuff with in, like, a data format like a JSON or a YAML, but equally found that we had to express all these   Boolean conditionals   and and things like that that just we were effectively, you know, trying to shoehorn a language into the JSON itself.  

[00:12:43] Unknown:

And so, ultimately, we landed on building a language for this, you know, special purpose. Yeah. It's funny how many times people start to think, I just need something declarative. I'll make it a static data structure. And then, you know, language constructs just start creeping   in. And then you have to have this whole other middle language around figuring out what the data model is actually trying to tell you.  

[00:13:03] Unknown:

Exactly. I use GitHub actions as an example of this a lot. Like, you have to go and look at the documentation for GitHub actions to know what the expression syntax is,   and you're not gonna get, you know, syntax highlighting or a debugger YAML file with some embedded   statements. You run it through CI,   and you have the slowest of other in the world.  

[00:13:23] Unknown:

Exactly. Yeah. It's pretty remarkable how long some people will hang on to YAML as saying this will work. It'll it'll be perfect eventually.   Yep.   And in terms of the DSL, I mean, you've talked a little bit about the motivation for going down that road because, you know, there's only so much you can cram into a YAML file.   But as to the actual polar language and the syntax,   how has   that   expanded your   scope of possibilities   beyond just writing a DSL in Python or   using this static data format? And what were some of the   inspirations that you looked to as to how to determine the syntax and the structure of that policy language?  



[00:14:08] Unknown:

The reason that Polar makes, you know, so much sense over something like Python is the logic piece of it. The thing about authorization logic in particular, it it tends to be a lot   of, like, decision flow, conditionals, you know, if the user has this role and this role allows them to do this thing, and this thing belongs to this other thing, then do this. Right? So typically, you write this in, like, an imperative style language. It's a lot of, like, if statements and, you know, lots of building conditions and things like that. This is effectively what, like, logic languages are are built to answer these kind of questions.   The original version of Polar was basically a simple Prolog variant. Prolog being 1 of the sort of long standing, well established approaches to logic programming, you know, used for, you know, wide number of use cases. That was, like, the initial inspiration was, like, building off of that. And indeed, like, the first version of Polo was kind of like a very small POC put together by 1 of the engineers over over a weekend. Just say like, hey. What do you think about this?  

And I was like, yes. That has, like, the conciseness,   you know, expressiveness that we need for representing authorization in a clean way.   Now the thing about Prolog, for those who aren't, you know, familiar with it or maybe learn about it in, like, comp sci degrees, I think it often comes up.   That's something people learn. The syntax isn't very friendly. It just looks weird. It's,   you know, uses things like, you know, semi colons for ors and commas for ands and and things like that. So it just looks very, very different.   And we we didn't want that to be, like, a barrier of people, like, learning, understanding this. So we sort of took the the initial prologue thing and we, like, iterated on a ton to try and see how we can make them more friendly.  

And, ultimately, we sort of ended up evolving this into something that looks more like Python. Right? So to do an and, you write and. To do an or, you do or. Like, we don't need to save you the characters. We're trying to use, like, the glyphs and symbols to do those kind of things. So sounds like a very important, piece for us.   Kind of the other really interesting or novel part of photo language   is that it has   language semantics for   host language objects. So host language in this case being something like Python. So you run polar embedded inside your Python   application. Right? So, you know, when you're evaluating the polar language, the rules,   it's actually able to access some of the Python objects, like attributes, methods, types, classes, all that kind of stuff for, like, how the rules are expressed and written. And so the language itself, basically, has those semantics. Like, you can   look up an attribute, and it understands it's gonna have to go and speak to the host language, whether it's, you know, Python or Java or Node or whatever. This, like, the language is built to be embedded in that way. There's also been  

[00:16:34] Unknown:

a kind of resurgence of policy as code in a number of different domains, most notably in kind of the cloud native   area where people are using things like open policy agent for being able to define   who can do what on different pieces of infrastructure within a Kubernetes cluster   and policies in terms of, you know, underlying cloud platforms with, you know, IIM from AWS or, you know, various other cloud providers. And I'm curious what other types of implementations   of policy frameworks   and configuration dialects and ways of specifying that information that you've looked to for inspiration   within your own work, either for positive inspiration or negative inspiration?  



[00:17:15] Unknown:

Yes. There's a few that come to mind. I think probably   the, you know, original authorization   policy language is 1 called I'm actually not sure how you pronounce it. Like, Exacamole,   x acml,   which is kind of very XML looking kind of thing for expressing authorization logic as as a policy.   Very, very, very powerful, but very dense and complex and, like, a lot of things to try and learn.   So there was also, like, a variant of that called alpha, which was, you know, kind of cleaned up syntax for the same kinds of things.   Those are some inspiration.  

The open policy agents language, Rego, was was definitely 1 we looked at for inspiration,   but ultimately found   that it wasn't so suitable for doing, like, application level authorization. It's more built around the model of being, like, a sidecar that you send data to, and whereas we really wanted that, like, tight integration into the application.   We feel like that's where, you know, for a lot of authorization decisions, you need to you need to look up data from the app, like, whether a user belongs to an organization, whether the resource they're accessing belongs to the same organization.   Like, a lot of that information exists in the app. We want to make sure that our language could sort of support that, like, tight integration.  

And I think probably the other 1 that's worth mentioning,   there's a Google project. There's a paper around this called Google Zandaba,   which is used internally at Google for doing authorization and access control for things like Google Drive and Google Docs, that kind of thing. So there, it's not really a full on policy language, but it's a   some kind of, like, configuration language for expressing   things like relationships.   So, like, those concepts like, you know, a file belongs to a folder, a document belongs to a folder, a user assigned a role on the folder,   and therefore, they have a role on the file. Like, it allows you to express things, like, mostly just in those, like, kind of relationship things. I think that the Zanzibar model is a very, very powerful 1 in terms of being able to represent   that 80% I was talking about of common use cases, I think, fall into that kind of bucket.  

And so we're sort of, like, trying to combine,   like, a bunch of that inspiration. I'd say it's, like, the power of that kinda like Sansa bar like model, but the flexibility being able to do   any kind of attribute based controls as well and, like, you know, additional complexities for the that last, like, 20%.  

[00:19:15] Unknown:

Kinda wanna, like, be able to provide all of that. And digging more into Oso itself, can you talk through how the actual library and framework is implemented, and particularly how you manage compatibility   across a number of different programming environments?  

[00:19:30] Unknown:

Yeah. So the language itself, Polar, is implemented in Rust. So the core of all of this is the policy language at the center.   That language is built in Rust.   So then we've basically exposed, like, a very, very simple API   to the additional languages on top of it. So   Python, Ruby, Java,   JavaScript, TypeScript,   Go, and then Rust itself,   as well works with this. And so those either talk through, like, a c like interface or something like Wasm with that, like, core Rust code. So, like, taking the pie the Python package,   you know, we basically compile down the Rust code into, like, a shared library and embed that in, like, the Python wheels so you can just, like, download that for whatever operating system.  

So there's, like, this kind of, like, very simple API between, you know, now Python and the Rust polar codes where it kind of forms this, like, conversation. It's almost like an event driven loop where   the Python side of it drives the language forward. It kinda says, alright. Here's my query. I want you to answer this question. And then it affects me calling, like, next a bunch of times to say, like, alright. Do a bit more work. Do a bit more work. Do a bit more work.   The reason it does that is because Polla can respond with things like,   hey. What's the value of Foo on x?  

Hey. What's the type of x? You know, is x a string or is it an integer? Things like that. So they have this kinda, like, conversation back and forth. So Python is, like, driving the query evaluation forwards by calling that next API, and the polar code is able to, like, ask questions back and get the information it needs   to, like, ultimately answer the authorization questions.   Every language runtime does that same kind of thing, which is really nice because,   like, it doesn't matter if you're running in, like, async node worlds or you're running in Python or Python with async or in Go or in Rust or whatever, like,   because the   because the host language is driving that conversation every time, we're not, like, depending on there's no, like, background threads. There's no, like, message passing or anything like that. It's, like, purely just driven from the host language.  



[00:21:23] Unknown:

Yeah. It definitely sounds   like it makes your life a lot easier by not having to maintain your own copy of the state and then try and reconcile that with what's running in the post runtime.  

[00:21:33] Unknown:

Right. Exactly. We don't need to, like, try and call back into we don't need to learn how to do a callback in every single language.   You know, the API is super simple JSON API with, like, a couple of methods.  

[00:21:43] Unknown:

And you mentioned that polar is able to   access and understand some of the methods or attributes of things like class objects and Python.   And I'm curious how you handle some of the   interoperability there and particularly   the policy   design if you're trying to maybe make it agnostic to the host language.  

[00:22:06] Unknown:

I'll give you the sort of the general answer, and I'll speak specifics about what this looks like. In general, we've actually found it somewhat rare that people really do need to share the exact same policy across multiple, like, applications, multiple different languages.   In these worlds where you have both a Python microservice and a JavaScript microservice and they are, you know, managing the same data, they're answering authorization of the same things,   that kinda defeats the purpose of microservices.   Like, often you,   you know, have done the whole, like, splitting up, decoupling microservice approach that you can allow them to manage different pieces of data. So in that world, it's kinda fine to have a different OSO instance on each 1, because they are only speaking or doing authorization logic over the data they kind of manage.  

I mean, the caveat is, you know, of course, there is gonna be some amount of, like, shared functionality. So maybe you have a, you know, like, a user service or a user management service or something that manages all the roles,   then, you know, each policy is gonna it's probably gonna wanna be able to, like, fetch that data and do the same kind of operations over them. And, basically, what you can do in that kind of world is just you can have the same, like, core logic shared and basically just have, like, a small shim on each different   on each different application to handle that, like, translation between   the stuff that really is specific to the microservice and, like, the kind of same general logic.  

But we've also got some we have this kind of model written up in in authorization academy about doing, like, like, hybrid authorization.   The idea being, again, like, each microservice just manages the data that it is kind of supposed to, that it's naturally been decoupled to manage. But it kind of, like, exposes   what it knows about the world from authorization as part of an API so that if you have that user management service, you can just ask it questions like, you know, I have a user who's trying to access this resource. The resource belongs to the organization.   Organization? And then if you get back an answer, you don't need to, like, duplicate the same logic because the microservice did it for you. It's kinda like the few different ways we think about this where   you can actually get pretty far with just like a single library per application approach. And any more that gets combined, there's actually a very natural way to fit that into   that sort of like microservice architecture where you get to keep the decoupling.  



[00:24:11] Unknown:

We've all been asked to help with an ad hoc request for data by the sales and marketing team. Then it becomes a critical report that they need updated every week or every day. Then what do you do? Send a CSV file via email? Write some Python scripts to automate it? But what about incremental sync, API quotas, error handling, and all the other details that eat up your time?   Today, there is a better way. With Census, just write SQL or plug in your dbt models and start syncing your cloud data warehouse to SaaS applications like Salesforce, Marketo, HubSpot, and many more. Go to python podcast.com/census   today to get a free 14 day trial and make your life a lot easier.  

As far as the  

[00:24:54] Unknown:

overall design of the system, I'm curious how the goals of the project and the actual implementation strategy has changed or evolved since you first began working on it. Yeah. So I think the biggest 1, which I kinda referred to at the beginning, was that we restarted out with the sort of the most powerful OSO, the policy language that allows you to do anything. And, you know, you can pretty much implement anything with that. You know, it's blank canvas. You can draw whatever authorization model you you would like.   The what we've been kind of seeing more and more is, you know, we've been growing, like, the open source community, and we've had people come and and speak to us and ask us questions about, you know, how's to do x y zed,   is that   there's actually a substantial huge lack of information   out there. I think people often struggle with is just is understanding, like, what they should be trying to build in the first place. Not necessarily, like, you know, the how is maybe they can work out, but, like, how should they even be thinking about this? How should they structure it? So that's what I'm talking about, you know, 80% of things like roles and relationships, models.  

We basically, you know, evolving also to being able to have, like, a very, very clear interface for those kind of things.   So, basically, we're taking, like, all the knowledge we have on authorization, everything we've learned, and giving you, like, an API for it. Fill out this template. Fill out this spec, and you will have the role solution you need as opposed to just being like, yeah. Yeah. You can build that. Oh, you wanna know how? Yeah. Yeah. We'll we'll tell you. We'll tell you. So we wanted to, like, take that extra step further and kinda get people up and running without having to do as much thinking about authorization as we have.  

[00:26:21] Unknown:

For developers who are actually working on integrating also into their application and they're trying to figure out how to structure their policies and integrate it into their workflow.   What is actually involved in starting to design a policy? How do you make it modular or be able to build abstractions over   different policy components and just the overall   process of maybe building a policy, debugging it, figuring out what's going wrong, sort of jumping into the polar code itself to try and step through what's the actual logical process.  

[00:26:54] Unknown:

To put it simply, as much as possible, we want people to treat polar just like application code. You know, the policy files, they live in your application alongside your application codes. You know, we also has a, you know, repl and a debugger, so you can indeed, you know, set breakpoints in your policy file and jump in and kinda, like, interact with them and see what's going on. You can, you know, print things out, so you can kind of see what information is being used as, you know, as it evaluates.   You know, and the same applies to some of the other stuff you're asking. Like, how do you how how do you break up the files? How do you, you know, pull things out into, like, abstract rules or something like that? It's kinda very much the same approach you take with with code. Like, if you have rule and it's getting a bit long and you see a common piece of logic shared across a bunch of different rules, then probably makes sense to pull it out and put it into its own rule. Again, I think some of that for authorization   where, you know, we're trying to kind of codify as best practices in in, like, examples.  

Like, it can be something like roles is kind of abstract, so we're sort of giving people, like, hey. Here's how you can structure that policy. Here are the right abstraction of rules and how to split it up to make your life easier. But otherwise, you know, it's kind of the same thing you do with normal code.   You know, refracture where appropriate. If you see the same pattern, you know, appearing, you know, 3 or more times, it's probably time to put it into a separate rule.  

[00:28:09] Unknown:

As to   the specific type of application that you're working with, where maybe you're working on a web app in 1 place and maybe in another spot, you're trying to build out a system daemon that's interacted via, you know, IPC calls. You know, how does that influence the way that you think about defining policies or the types of permissions that you might need to work with?  

[00:28:31] Unknown:

I'd say we've primarily been focusing on kind of web apps. A lot of the patterns that we we haven't shared, I think, are focused around   that, you know, web application with with things like roles.   But a lot of the concepts   really comes down to the same thing. It's   trying not to think about   authorization as being its own distinct concept that somehow is, like, independent of everything else that exists. But, like, as near as possible,   describe authorization   in terms of what you already have and know about your app. So for example,   the way that we kind of envision someone getting started with providing a policy and, like, a web app is just, like, start describing to us what you know about your app. What's your user model? You know, do you have, like, a user class? What are the resources you're trying to protect? You know, I have an organization or a repository in a project or something.  

What are the relationships between them? You know, our repositories belong to organizations   and, you know, there's a key on you know, there's a organization ID on a repository that is how you figure that out. Once you kind of, like, have built up the some of those, like, pieces,   it then actually becomes, like, very natural, I think, to just express what you're trying to do in terms of those. I've said these a bunch throughout. Right? Like, you know, you can, you know, user can read a repository if they're in the same organization as their repository or some say as their repository.   So I think oftentimes people, like, try and wrap their heads around authorization models and what does RBAC and ABAC mean. And really, it should just be   how close can you get to describing   the, like, natural language version of what you're trying to do. Can you express those concepts inside your policy language? And then can you just combine them together simply?  



[00:30:02] Unknown:

And as you work with   end users of Oso and you try and iterate on the project itself, what are some of the   common mistakes or areas of confusion that you see people run into as they're getting started with the project?  

[00:30:16] Unknown:

Yeah. So I think 1 of the things that I've seen is, like, an moment is when people wrap their heads around what it means for PoE to be a logic programming language or to be declarative.   So for example,   you you don't need to, like, initialize a variable. You don't need to   assign a value to a variable. You kind of just write in your rules what what you want to be true. It's kind of the idea of declarative rights. You just you put down, here's what I want to be true. Here are the rules that I want to be enacted in my application.   This can be kind of counterintuitive   because,   you know, you can write, like, an allow rule and, you know, the second parameter, you can just put, like, the string reads, or the second parameter could be a variable action.  

And, you know, behind the scenes, like, polar is gonna do sort of, like, passing matching. This process called unification where it's effectively gonna be matching variables and and, you know, if the input variable is is a read, then it will match, you know, both of these 2 things, otherwise, it'll match 1 of them.   And, you know, the kind of the idea is is, like, you don't need to tell, you know, also or Polo, like, how to do the thing. You just need to tell it what, and we work out the how. I think it can, like, take a little bit of time to get that sort of, like, a how moment to really click the that's the sort of,   you know, workflow that you have in writing rules and then kinda, like, seeing it happen. So I think a lot of us are kinda geared towards thinking   maybe more imperatively, like, this will execute than this and this and this as opposed to just, like, expressing   like I said, you know, like, I just wanna express, like, there's a relationship between these 2 things. I now have this, like, piece that I'm gonna use throughout my throughout my policy.  



[00:31:41] Unknown:

The other piece of sort of running into confusing bits is that people might decide, you you know, here's a feature that's useful and then maybe use it as a crutch and not explore all of the capabilities of the framework. And I'm curious,   what are some of the often overlooked or misunderstood   capabilities of Oso that you think people should spend more attention on or be aware of as they're starting to explore the project?  

[00:32:03] Unknown:

1 of the, like, most powerful things I think you can do with Oso is very   fine grained authorization that doesn't feel,   like, overly   complex.   So I think a lot of people naturally wanna gravitate towards doing, like, a like an authorization middleware, maybe on, like, the route level kind of thing. So   inspecting the request that comes in and looking at the path and trying to answer whether that should be allowed or not, which can be very tempting because it means you get to just put, like, maybe authorization in 1 place at, like, this entry point to the application.   But, you know, that can often be kind of restricting and make it harder to write some of these policies or acquire you, like, looking at redundant data. I think, like, the real power of also comes when you start, like,   you know, seeing authorization as this, like, pieces, like, lives throughout your system, throughout your application,   And just, like, dropping in, like, the is allowed calls, like, in, you know, and all, like, the controller methods. Like, if you have a piece of access, just, like, dropping in is allowed in there. And you can just pass in, like, you know, any resource. I mean, it could be a string, it could be a request, it could be an object, and you can write rules over those.  

Like, not kinda constrain yourself to only having, like, 1 kind of authorization, but just, like, thinking about how it can be, like, woven in everywhere. I think that can be yeah. So often we see people maybe get, like, stuck at, like, the first piece. They just, you know, think about things on, like, the route level when really they could be doing, you know, some really great stuff. And  

[00:33:19] Unknown:

that kind of plays into a bit of what we were talking about before with microservices,   where I'm curious   how you think about how to   start to approach the design of policy definitions for a system as a whole when it's composed of different microservices   and being able to  

[00:33:37] Unknown:

pass off the useful pieces of information for the different downstream policies to be able to key off of. I'll start by explaining a piece of parallel or so that's useful for this. So 1 of the things that's nice about   logic programming as kind of as a whole is you can generally ask it, like, flexible questions. So you can ask it, you know, can a user read this resource? But you can also say,   you know, what are all the actions this user is allowed to perform on this resource? And it'll maybe give you, like, a list of those strings.   So where this can be useful is it means you can start,   you know, sort of like annotating some of your data that gets returned by an API with, like, the user's capabilities on that resource.  

So maybe I have, you know, I have my repository service and I query it and I get back the repository   data, but then I also get back, like, the list of all the things the user can do. I can now, like, plug that information into, you know, whatever other microservice I have. Now the full, like, understanding.   From that microservice's understanding, these are all things the user can do on this repository.   I'm a downstream consumer of repositories, and now I know that, like, I should or shouldn't allow,   I know, the users to create this branch or something. Maybe I'm the maybe this is the git service or something handling branch creation. You kind of now have all the information you need on on, like, the permissions.  

You know, in this world, you haven't had to,   like, recouple the data sources   because authorization does often try and touch, like,   all parts of data.   The idea is, like, you can still draw those, like, nice decoupled boundaries around your microservices   by just allowing them to answer more flexible questions on authorization.   I just think that's just something that hasn't really been explored enough as a design concept and something that we're kind of looking to help support.  

[00:35:09] Unknown:

And that's starting to sound a little bit familiar too in terms   of OAuth scopes as far as this user is authenticated.   Here is a token that they have created for, you know, some third party to be able to perform these actions, whether that third party is likely to be another piece of software. And it sounds like also is kind of a natural fit for being able   to design and implement those scope constraints within the application.  

[00:35:33] Unknown:

Yeah. Absolutely.   Adding, like, scopes on a token is another really interesting,   like, possibility. I think it can be very useful just for this is maybe not, like, directly the same as their kind of original OAuth purpose, but I think around things like API tokens. You know, maybe as a user of the app, you wanna create a 1 off, you know, API token, but all it should be able to do is reads. So you wanna be able to, like, add that, you know, restrictive missions to just read actions.   I think it can definitely be really useful in that kind of context   where you can maybe take what the existing user already has and then, like, restrict it down to, like, a small number of things.  



[00:36:05] Unknown:

And as you have,   as you mentioned earlier,   you're building this as part of a startup and also itself is   going to overall governance strategy around the act the open source component of what you're building.  

[00:36:27] Unknown:

You know, everything I've spoken about today is part of the open source offering. And, you know, at least, like, 6 to 12 months is really on growing the open source community and adoption.   The stuff we spoke about at the very beginning, we really just see there as, like, a huge opportunity and a huge chance for us to   provide, like, a consistent way of doing authorization across any application or language. So So that's really where we're, like, focusing on now in the short term. In the over the kind of the longer term, some of the stuff that we've, you know, spoken about doing as, like, a commercial offering   would be   effectively, like, supporting more of, like, an operational security   pieces of doing authorization across, like, larger deployments.  

Something that we speak to with people about a lot is auditing,   both internally and externally.   Being able to say to, you know, say, like, a customer or end user,   you know, so and so was compromised, and you wanna know what they did. Yeah. Here are the resources they accessed over the last, like, 6   months. Or similarly, you know, being asked ask questions like, what are all the resources this person has access to, and why? Like, why do they have access to that? Oh, because, you know, they have this such and such a role. That's kinda like the external facing version, but also, like, internally, you know, it can be very useful to be able to look back and see   what requests were made and not just like what, but, like, why. And that can be, like, tied back to the policy.  

So that's just kinda like an example. The kind of thing that we're looking to build into our sort of commercial offering is ways that, you know, help extend those   individual also instances   running in the apps with, like, additional stuff often comes up around  

[00:37:49] Unknown:

product security or operational stuff and things like that. And so does the current state of OSO allow for that type of exhaust of   the types of questions and answers that are being asked of the policy engine itself and being able   to log the interactions with the polar language?  

[00:38:07] Unknown:

You can definitely, like, log their request and capture the requests.   But the kinds of things that would be,   I think, difficult for someone to build on them by themselves right now would be like an efficient way to capture   the why pieces.   I think for example, today, you could log, you know, what was the request and maybe, like, you know, a hash of the policy so you kind of have, like, a version of the policy effectively. With With that information, you could, like, recreate the, you know, the why that request was allowed. But some of the stuff that I think, you know, we'd wanna provide   goes towards more of the, like, you know, what are all the resources this person could access? You're now getting into, like, searching over policy decisions, which could be a lot trickier.  



[00:38:45] Unknown:

Talking about things like being able to generate an audit trail of who has interacted with what resources and being able to figure out what policy decisions were made and why   come you know, brings to mind the question of performance impact. And as you go down that road,   that's something that I'm curious to understand a bit more, but also just in the current state of embedding this policy engine into   your application, the types of overhead that it incurs, and the work that you're doing to   measure and reduce the overall impact that it has on people who are embedding Oso within their applications?  

[00:39:20] Unknown:

So policy evaluations themselves,   you know, for a regular resource, typically take on the order of, like, several milliseconds.   So I think on, like, a per request basis, that's, like, pretty acceptable.   There's actually a lot more we want we want to do there. The main area where this web performance   becomes, like, on the orders of magnitude where it really matters is around   formally doing authorization   over, like, batch amounts of data. So for example, if you wanna be able to list all of the resources that someone has access to, in the naive case, you're fetching the whole database and going through each 1 and saying, can I read this 1? Can I read this 1? Can I read this 1? And so on. That's the 1 where this gets really bad because then that 1 millisecond becomes, you know, 10, 000, 000 milliseconds or something.   So to address that, we have this feature called data filtering,   where we actually are able to take the policy evaluation. And instead of just outputting a yes or no answer, we'll actually output, like, a set of constraints or expressions   for what resources can be accessed.  

And then we have, like, adapters with things like, you know, Django and SQLAlchemy that will convert that into a query filter. You know, with the same policy that you'd use to answer these authorization questions,   you can then go and filter your database by   everything this user can can see, for example.   And that's where the performance really matters because then you pushed it down to the SQL layer. It's just become, you know, a case of SQL where clauses as opposed to  

[00:40:39] Unknown:

fetching all of the data. That's kinda like the main area we've invested in to make sure that this can stay performant over, like, the typical use cases you need. Yeah. And that also brings up the specter of how you're designing the policy itself because with the fact that you can look up attributes on objects that live within the host language, there's definitely the possibility of, know, triggering an n plus 1 query case or,   you know, doing an expensive lookup on an object multiple times or, you know, doing sort of the naive approach of looking up this attribute in this section of the policy block and then another attribute in the other as policy block where in Django, for instance, each of those attribute looks lookups is actually a SQL query. So,   curious   some of the potential edge cases that you've seen people run into that can cause some of those cascades of performance issues?  



[00:41:29] Unknown:

Yeah. That's definitely an area that's possible. There was kind of an early   trade off that we decided around   how much we should try and solve that kind of problem versus how much we should,   you know, give the user the tools to to solve them.   In the general case,   like, if you're writing a regular policy over your attributes and methods,   we try to be pretty transparent to what's happening on the surface so you can, you know, optimize as necessary and that we're not, like, obscuring the details too much. Like, if you have an n plus 1 problem, you can solve that by the same approach you take in your application.   There's not, like, an opaque barrier to you understanding that. So that's kinda like in the general case. In the case of data filtering, that effectively   isn't a problem because everything you express over your is getting pushed into that, like, 1 evaluation in in the database. You know, so there's maybe some amount of work where   you might, for example, like, fetch a bunch of attributes about the user first and then use those to perform that query. But, generally, you can, you know, achieve everything you need to in, like, 1 or 2 queries.  



[00:42:25] Unknown:

As you have been building out Oso and introducing new people to it and working with end users, what are some of the most interesting or innovative or unexpected ways that you've seen it used? Oh,  

[00:42:37] Unknown:

there's quite a range.   1 of my favorites just from a novelty perspective,   we had a a group of students from NYU who were doing this as as like a class project. They actually built a a poker app.   So for playing, you know, Texas holding poker, he was using POLAR to power the, like, hand scoring logic   to express things like, you know, what a full house is and, you know, using polar and use that as, like, the engine to power the app. So I think that's kind of 1 of the more fun sides of this. I think that's, yeah, 1 of the most novel ones I've seen.   On the more, maybe, practical ones, I think 1 of the there's someone who's building a sort of, like, a public key infrastructure tool that uses some pretty complex policies   and also using polar as the way to expose   the configuration of authorization and permissions to their end users.  

So, yeah, this is a tool. It's just primarily, you know, aimed at, you know, other engineers to, you know, build and set up, you know, this public key infrastructure.   So there, they just basically made the customisation for their authorisation just to be powered by Polar. So they just basically provided some of that out of the box, but then just, you know, it's kind of a blank slate where it's like, if you need to customise this, go ahead. You can write whatever policies you need. I think that's a really nice example of some of the stuff that we'd like to see happen more and more, like, over the long term, is that this just becomes a   kind of widely accepted way of doing   expressing authorization  

[00:43:53] Unknown:

in your app and other people's apps and so on. It's definitely cool that they were able to just expose that policy language directly to end users and say, go nuts.  

[00:44:02] Unknown:

Yep. And not reinvented themselves from scratch and so on and so on. And yeah.  

[00:44:06] Unknown:

They didn't wanna just translate it into YAML and then feed that into Poland?  

[00:44:12] Unknown:

No, Clyde.  

[00:44:15] Unknown:

And so in terms of your experience of building Oso and trying to grow the user base, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?  

[00:44:25] Unknown:

1 of the things that's been pretty challenging and definitely rewarding in building Oso is that we've been interacting with so many different   language and framework communities.   So pretty early on, actually, we had someone who's very involved in, like, the authorization of permissions   kind of implementation from the Django ecosystem, like, joined our community and gave us a ton of really interesting feedback   on, like,   the idiomatic way of doing it there and how to fit in with ecosystem.   But then, you know, similarly, as we've been building out across different languages,   you know, the way that, you know, so should work in in Go is pretty different how it works in Ruby. And so it's always very, very, like, interesting to have people   who   are way more experienced than I am in these other languages to kind of come and just help us understand, like, how they would expect it to work and, like, how these things would normally normally go and just kinda, like, give me exposure or give the whole team really exposure to all these different languages and frameworks. It's been it's it's been a lot of fun. And for people who are looking to increase the  

[00:45:23] Unknown:

granularity or flexibility   of their authorization policies in the applications that they're building   or that they're building or the systems that they're trying to design? What are the cases where Oso is the wrong choice?  

[00:45:33] Unknown:

So I think, honestly,   if your application   is   maybe something like a   social media app, maybe it's like a b to c application, something like that where   you may be unlikely to have, like, a lot of complex logic,   then it may be better off that to, you know, to skip the complexity of adding this additional solution.   Like, I think we're sort of optimizing for,   you know, a certain level of complexity   that I think is very typical in   b to b applications.   I wouldn't want, like, everybody out there to think suddenly that, like, authorization is,   you know, roles is something that they absolutely must add to every single application. I mean, like, you use Twitter on a daily basis. I don't have a Twitter role or anything like that. I'm just a Twitter user, and I can see a bunch of things.  

I mean, there may be times where social media can be interesting because maybe a lot of, like, graph based authorization permissions things going on there. But I'd say, like, on the whole, if you're building something,   maybe an ecommerce app or something like that, then   your authorization concerns might not be that complex.  

[00:46:31] Unknown:

As you continue to build out the project   and iterate on your product division for go to market in your business, what do you have planned for the future?  

[00:46:40] Unknown:

So as I said, the the thing I'm most most excited about is the upcoming work we have on   effectively giving you a, you know, declarative way to express to build and create roles into your application using Pola.   Everything that's gonna be pretty game changing in in how people   engage with roles as a concept in their app. And I think from there, we're just gonna kinda, like, keep building on top of that and adding things like, you know, new ways of new different types of authorization modeling,   new extensions to things like, you know, relationship based access to, you know, ways to do route level in the easier way, giving people more control and, like, APIs for how they, you know, manage things like roles inside their app, integrate a new piece of data.   Like, I think,   you know, today, you know, authorization is kind of like this small kernel of an app, and we sort of, like, wanna grow it out across all parts. So, you know, end to end from, you know, everything you need to build in. UI to expose this to users, to the back end, to the database, like, we're gonna start being seen also used across, like, the whole stack.  



[00:47:36] Unknown:

Are there any other aspects of the OSO project or authorization  

[00:47:40] Unknown:

and system design for being able to enforce better security policies that we didn't discuss yet that you'd like to cover before we close out the show? I guess, like, 1 of the other sort of longer term, well, maybe medium term things that we wanna be doing with polo, which I think is gonna start reassuring the benefit of the approach, is having things like   built in linting, validation, testing, stuff like that. Because I think once you have, like, you know, your effectively, like, a specification for your authorization   written in polar, there's a ton of, like, really cool things we can do that I'll start giving you advice around, like, you know, there's a resource that accidentally hasn't been protected or, like, the, you know, logic is messed up and everybody can access this 1 thing. Like, there's a lot of really cool you can start doing that once you've kinda got it expressed in that in that standard  

[00:48:23] Unknown:

form. I'm really excited about some of that as well. And those 1 of the things I had actually meant to ask about earlier is with the polar language itself, what type of editor support is available for people who want to be able to get useful syntax highlighting or,   you know, any sort of error reporting or linting available for the actual policy specification.  

[00:48:44] Unknown:

We have some amount of, like, linting and warnings built into the language that would just, you know, print out in any whatever language you were using. ID support specifically,   but we have   support for Versus codes. And, actually, we just recently had a community member contributed Vim syntax highlighting as well. So those are the 2 ones we support currently.   I would absolutely love for us to have a language server implementation for polar. I think there's a ton of really cool stuff we could do there. We are just well, we have a lot to do.   The perennial problem. The perennial problems. Yes.  



[00:49:16] Unknown:

Alright. Well, for anybody who wants to get in touch with you and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And so with that, I'll move us into the pics. And this week, I'm going to choose the movie chaos walking. I just watched that a couple of days ago, and it was actually very well done, very interesting,   real really sort of interesting   concept of everybody being able to see each other's thoughts, just the types   of social impacts that that has as as people trying to settle on a new planet and kind of, you know, being unexpectedly exposed to this. So definitely really well done movie, good acting, good sort of concept,   something worth watching if you're looking for something to pass the time. And with that, I'll pass it to you, Sam. Do you have any picks this week? So I've been playing a lot of the game Hades on the Switch.  



[00:50:01] Unknown:

It's a really fun game because,   I mean, I don't wanna give too many spoilers away, but, basically, like, you know, it's like a roguelike, but every single run through, basically like, a lot of the variables and strategy and stuff like that changes. So if you kinda, like, enjoy,   you know, RPG style games where you kinda get to create a character, it's like that, but every character is only gonna survive for, like, half an hour tops, and you get to build a brand new 1 and, like, pick a complete different skill tree. If you like that kind of thing, which I definitely do, then it's a really fun way just to do character building   again and again and again and again. It's also very convenient if you don't have, like, tons of time to play, because you can kind of do, like, a run through, as I said, in about half an hour and move on unless you get stuck in the sort of just 1 more game loop.  



[00:50:41] Unknown:

That's the other perennial problem.  

[00:50:44] Unknown:

Yeah. The perennial problem.  

[00:50:46] Unknown:

Alright. Well, thank you very much for taking the time today to join me and share the work   that you're doing on Oso. It's definitely a very interesting project and 1 that I plan to take a look at myself for my own project. So I appreciate all of the time and energy that you've put into helping developers build more secure applications. So thank you for that, and I hope you enjoy the rest of your day. Thanks for having me.   Thank you for listening. Don't forget to check out our other show, the Data Engineering Podcast at dataengineeringpodcast.com   for the latest on modern data management.  

And visit the site at pythonpodcast.com   to subscribe to the show, sign up for the mailing list, and read the show notes.   And if you've learned something or tried out a project from the show, then tell us about it. Email host@podcastinit.com   with your story.   To help other people find the show, please leave a review on Itunes and tell your friends and coworkers.