Building Smarter Authorization Systems with Sam Scott

Transcript

Sam: What is sort of the right way to do it that will lead in a good user experience for your customers? Right, not just about, like, what is good, you know, how can you implement this in a way that gets off your roadmap, but like, what do we think would be truly like, delight your customers with?

Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today on this promoted episode is brought to us by our friends at Oso. And what else is brought to us by Oso? That's right. Their CTO and co founder. Sam Scott. Sam, thank you for joining me.

Sam: Hey Cory, thanks for having me.

Corey: Oso makes it easy for developers to build authorization into their applications.

Corey: With Oso, you can model, extend, and enforce your authorization as your applications scale. Organizations like Intercom, Headway Product Board, and PagerDuty have migrated to Oso to build fine grained authorization backed by a highly available and performance service. Check out Oso today at OsoHQ. com, that's O S O H Q.

Corey: com. Instead of starting at the beginning, because that makes way too much sense, I want to pick up on something that I noticed about your background. Specifically, you have a PhD in cryptography. Which, uh, my, my biggest takeaway from this was always called Schneer's Law. Which is, as Bruce Schneer famously said, anyone can invent an encryption algorithm that they themselves cannot break.

Corey: The takeaway, of course, is don't roll your own cryptography. And the other thing I try never to get involved with is rolling my own authentication. So you have a PhD in cryptography and now you work for a company that does authentication. Are you just like effectively hanging out with a bad idea bear or something and coming up with these ideas?

Corey: What is your life like? How did you get into this position?

Sam: I mean, someone's gotta solve those problems. And I, I, I, I like the hard problems. It's, those are my fun ones. I, I will have to correct you immediately with the misconception that almost everybody makes. We work on authorization, not authentication.

Corey: Excellent, excellent. And I want to begin with an even dumber question then. What is the difference between the two?

Sam: So authentication is typically about identity. Like who are you, right? You, username and password, single sign on. Like, how does the other person, the other side of you know, some interaction, know who you are?

Sam: That's like the authentication piece. Authorization is normally what comes next. Like, now that I know who you are, right, you're Corey in some domain, I know you belong to some organization, like, okay, now I know who you are, what can you do, right? Can you research such documents? Do you have access to certain features?

Sam: Things like that.

Corey: In other words, great. So when I start, uh, having too much to drink on a plane and ranting, like, you don't know who I am, I'm Corey Quinn. And they'll say, yes, we know exactly who you are. No, you're not allowed to fly the plane.

Sam: That is exactly right. Yeah.

Corey: Got it. I somehow don't imagine that's going to be making it into one of your, uh, one of your slide decks anytime soon.

Corey: But no, it's, it's an interesting problem. And someone that I once worked with in the early days of my career pointed out something that at the time I, a, uh, wet behind the ears 20 something who of course knew better, scoffed at it. But they said that ultimately every, every security and networking job in its final form becomes about identity and access management.

Corey: And I laughed and I laughed and He was really onto something in hindsight.

Sam: Yeah, uh, I mean, basically what you're summarizing is how I found out my PhD was worthless. Have you heard the expression, turtles all the way down?

Corey: Oh yes, the world stands, what was it, what's the expression? There's some mythology that said, oh, the entire world exists in the back of a turtle.

Corey: Plausible as anything else. So what's the turtle standing on? Another turtle. It's turtles all the way down.

Sam: Exactly. And so the same thing is true in, uh, in security. And this is kind of what I found out with, with working on like interesting cryptography, which is, so I know some of the stuff I did was around like, how do you make sure that like data was encrypted?

Sam: And like, if the keys change, you need to rotate them and so on, so on, so on. And like, there was definitely some like interesting technical problems to work on. I had a lot of fun and built some fun mounts. When you get to, like, the, in practice, what is hard about keeping data secure, it's like, who has access to your keys in KMS, in Amazon KMS, right?

Sam: Like, you can get those keys. If you can get the keys, it's game over, right? It doesn't matter what encryption standards you use and how frequently you're rotating your keys. It's a, oops, I wrote a, I wrote an access control rule that let somebody get access to the product encryption keys and now it's game over.

Sam: And that's kind of where the authorization piece comes in, right? It's like, you know, are you making sure that the right people have access to the right? Things. Maybe not the bottom title, but it's definitely a pretty low one.

Corey: I know they're not the same thing as you just corrected me on, but I, I can't shake the feeling that I'm not the only person that makes that mistake.

Corey: Take AWS as a terrific example. Please, take it. Take it somewhere far away from here. The problem that I have is that by authenticating that I am me to my AWS account, the only way that is expressed is in the form of credentials. And ideally short lived ones because I'm not a complete lunatic. There's no distinction to my mind between, yes, I have the credentials to prove I'm me, and also by extension, by being me, I therefore have access to do the following number of horrifying things.

Sam: Yeah, deeply, deeply coupled related problems. Right. So it's the kind of the one you described, like, you know, I, you know, I authenticate, identify who I am. And like, I belong to, I'm inside of an AWS organization or account, and that's going to give me access to a bunch of things by probably by default, right?

Sam: Like almost every app in the world is going to have some amount of like authorization that's maybe not expressed very explicitly as like, this is authorization happening right now. But it's just a. Okay. Cool. You know, when, you know, when you go and read the database, you filter by an org ID or something like that.

Sam: Like that is, that is authorization, but it's kind of. implicit, it's like woven in, but it starts getting more and more interesting when you start getting to more like more complex, fine grained versions of that, right? So sure, you've done, you've done some of basics up front, you've identified you, you've put in your credentials, you get access to some things, but your AWS account probably has a ton of IAM rules describing the precise resources that you have access to at any given time.

Sam: In fact, if you do things correctly, and, you know, maybe I've coined the best practice, you might not even have access to things directly. You might have access to assume a role, and that role might grant you access to things. And that is another really good example of, like, authorization. It comes up everywhere, like, role based access control.

Sam: The general idea being, instead of just describing what Quarry can do, I say, well, Quarry has this role, much, much like other people in this organization do, and they can all collectively do the same kinds of things.

Corey: Now, that's exactly what we do, and in most accounts that I have, that role lets me assume administrator access, and the reason being is that I've always viewed AWS accounts as being the ultimate trust boundary, because it doesn't matter if you just have developer rights and can never touch the things in the production side of that account.

Corey: Things like service quotas, there's no way to restrict those. So suddenly you, you run out of a script that runs a muck. You're not going to be able to suddenly auto scale in the production side of the environment. So there has to be that boundary there somewhere. But we, I do this through IAM Access Identity Center.

Corey: The source of authentic, the source of identity is Google workspaces. And then I wind up assuming roles based upon my group membership inside of that. And that gets me most of the way there. There are then additional roles, we assume, in client accounts where, surprise, I don't want to be able to break things there.

Corey: So, it tends to be very narrowly scoped to begin with and we can scope that further when we have customers in particularly sensitive environments. We, like, do not break production or you're not allowed to save money anymore has always been our, the thing that we've observed in our client accounts. But being able to assume those roles correctly and make sure that the right people who are working the right account have access.

Corey: We don't just grant, oh, everyone here can have access to everything. We, for a small company, we do a remarkable amount of segmentation just because I, I've worked in regulated compliance heavy environments before. You want to keep the sensitive stuff as narrowly contained as you can because then you don't really have to worry about access at all.

Corey: outside of those things. Well, okay. We have to make sure that all the discussion of the sensitive client stays within a, uh, a given bounded area of Slack where only certain people can access. Great. So we codename everything and then it's a lot easier just because in case someone slips, we aren't suddenly now having to deal with data breach issues.

Sam: Right, exactly. And so like building, building an authorization system is all around. I guess enabling users of your own product to be able to support the flow to make the most sense for them. And with something very like platformy, like in like an Amazon, right? Like naturally, you're going to want to give your users a lot of flexibility so they can tailor things to exactly how they're setting things up and building things.

Sam: But in a lot of cases, while you maybe, you maybe want to give people like minimal configurability, you want to just give them the typical path they would take and not think about it too much, for example. So it's kind of a wide spectrum.

Corey: Yeah, it's a, because the problem that I've found, and this is where I start to get political on it, so you'll have to bear with me, but I've been saying for a while that Google is number one when it comes to security, and AWS is number two.

Corey: And Azure is, did not finish, they're at the kids table eating crayons, as they're going to do. Terrific. And the reason behind this is the usability approach. By default, anything in a Google Cloud project can talk to anything else in a Google Cloud project. That works terrifically well for me, and disastrously for people at a bank.

Corey: But by the time you're a bank, you have an InfoSec team that can disable that behavior, and build in a, uh, leased access model, which is great. Microsoft The danger of the AWS approach, and I gave a conference talk recently at an event that Wiz threw that it was, it was about an actual screenshot of something I have hanging out in my code build environment where I have four or five different policies assigned to it.

Corey: And the last one that I added was administrator access. And there's a to do to go back and fix this later. And this was in 2018. I have not yet gotten to do that yet. And it's because you try to do something, it doesn't work. You expand, try again, doesn't work. And if you're doing this through something like CloudFormation, each iteration takes an hour.

Corey: So great. By the time I was finally, right, it was the hell with it. I just want this to go. That's the problem with continually failing to get the right permission dialed in. So you just say, just, just go ahead and give it to me everything. I'll deal with it in my own time.

Sam: Yeah. You're, you're, you're appreciating the client, yeah.

Sam: Much like how roles can be this like pretty convenient authorization abstraction to like group people together based on similar things they do together. These are all admins, right? Like similarly on what I think about as like the resource management side, like the entities you have access to, having that ability to just like group things into some kind of hierarchy with like orgs and projects.

Sam: It's like such a simple model for you to wrap your heads around, but like, it gets you so far, like as you described, just being able to do that level of like opinionated structuring of missions goes like a long, long way.

Corey: Yeah, I'm very interested to see how these problems evolve because what we're currently doing is not sustainable.

Corey: Clearly, it's not. And Uh, the thing that I figured out as I went down this path early on when I started doing this independently is I turned my nose up at anything that would look like Arba, rba C or SSO because I was independent and I already have a great SSO thing that works. It's called One Password.

Corey: I stuff all of my passwords into it and things are great. The where this starts to break down is when you start dealing with other people. How do you validate that? Everyone is using one password, for example. Well, when you mandate SSO, that solves some of these things, and you have a single choke point to wind up controlling access and enforcing MFA and the like, whereas having to play whack a mole at other environments.

Corey: That was something that I found to be extraordinarily challenging, and I wish I'd done a bit differently setting out to do it. Yeah, in that it's, it's nice to be able to have a single dashboard. When I bring someone on as a contractor to work on a project, for example, there are certain levels of granularity to permissions that they should have.

Corey: And they vary from contractor to contractor. Having a catch all contractors group doesn't work. It has to be, okay, are they a contract cloud economist? Okay, great. Which accounts are they working on? Make sure they only have access to those accounts. They still need access to shared stuff internally, but they probably don't need access to, for example, the employee portal and so on and so forth.

Corey: And in each one tends to be these bespoke things. And honestly, if I'm being direct, what we'll see is great. We just have a pattern that we apply to most contractors that start based on the template that we built from our first contractor.

Sam: Yeah. I think the world you're kind of. Getting towards here reminds me a lot of SAML.

Corey: SAML, OAuth, SSO, these terms are, these terms are inter, uh, interact, uh, I guess, interact inter replicably, just between things. All the documentation for all of these things, in my experience, presupposes that I have a directory management background. Everything would assume I know what an OU is, which, okay, great, not everything lends itself to the OU model, especially when those OUs are not hierarchical, and it becomes an obnoxious, painful problem.

Sam: Yeah, absolutely. I mean, I think the thing that's nice about SSRM Secure is because it creates, as you say, it creates that like pretty clean, convenient choke point where it's like, as an, as an implementer, I don't really need to care too much about how you authenticate like somebody else, your, your IT admin decided how someone should authenticate.

Sam: And like, once you're in and authenticated, like I can kind of continue on and do, you know, do, do the stuff that I care about. When you get into like trying to do that or an authorization standpoint, I mean, like you described by bringing in Google workspace groups to use those to determine which roles you can have access to.

Sam: That's when you end up in like the gnarliest of gnarly, like federation problems where yeah, you're talking about three or four different standards, protocols, specifications to implement to get that data. Nobody does it in the same way, even though there is technically a standard. And then you need to go and use Implement an interface inside your app that lets your users configure how they want to connect those different pieces of information up and decide what they can do with it, right?

Sam: Like, I'm out of breath just trying to talk about it. I know there is It's like, it's like that classic, you know, XKC cartoon, like I'm just going to create a new specification to standardize over all these things and build that one and then we have another new one

Corey: and so on. Congratulations, you just built the latest standards.

Corey: No, no one, no one sets out trying to build something bespoke and unique, like, ah, we're going to build a unification thing. And unfortunately, it just doesn't work.

Sam: It's a thing for us, like, I think. It's, it's, it's, you know, it's kind of a two sided problem in both of which are hard. Like it is both hard to build a like authorization system that allows you to kind of bring in arbitrary external data and let people configure that and manipulate it into how they want to do authorization inside of the product.

Sam: Like that side of it is already hard, let alone the like abstraction or unification of the like, you know, where that data comes from. And so at least for us, that also like, we can make progress on solving the first of those two problems. And we make it easy for people to implement. Cool, I have groups from Google Workspaces and I want people to be able to use that inside of my products.

Sam: We can make, we can solve that half of it at least.

Corey: That's the painful part. That's the thing that's hard, in my experience, to get right. It's the, it's always the new thing suddenly turns that, turns everything you've been doing on its head. And I think at enterprises, this gets a lot easier because there aren't that many new worlds left to conquer.

Corey: Uh, you, you are not the first person who tries to expense a rental car at a company that has 2, 000 people. But when you're 10 people, maybe you are when you grew during a pandemic. So, I'm curious to know, on some level, what, what is it that you folks do, exactly? I mean, so why should I use, why should I use Oso to wind up solving these problems?

Corey: Because you already have some compelling, uh, stories, like, well, honestly, our logo is a bear and we're named after the Spanish word for bear, so, terrific. The puns are going to be there for days, but that, that drifts a little bit too much into my personal la bears. What are the, what are the reasons that you exist?

Corey: What is it you solve for customers that hurts?

Sam: Yeah, so the reason that we exist is, I think there are probably two main reasons. So, so first of all, something that we just observed is that people have been reinventing this wheel of authorization again and again, like every single company they went to, they've spent like six months, 12 months, you know, multiple years re implementing authorization within that company.

Sam: Like, how do people, you know, how do people get access to stuff inside of this product? Rebuilding. You know, organization roles, user groups, rebuilding, you know, the ability to share things with people and give them access to it. Everyone's just like rewriting this code again and again and again from scratch.

Sam: And so it just kind of seemed like one of those, those obvious problems that like, what if that was just a company that could solve that for you? So that is like that side of it. We just like help take that implementation away from people. I know like, I love authorization. I think it's a super interesting problem, but I don't think like every company in the world wants to be authorization experts and crush it.

Sam: And so I think it's one of those problems that's like. A really good fit for people to like outsource somebody else. I think the other half that maybe touches on some of what we've just been talking about, which is people don't really, people don't really talk about authorization a lot. They don't think about it a lot and like talk about what is good authorization, a bad authorization, or like have compared, you know, AWS IAM, you know, Google Cloud Approach much in depth.

Sam: We have, but we have like a lot of opinions on like what is the, what is sort of the right way to do it that will lead in a good user experience for your customers. Right. Not just about like, what is good, how can you implement this in a way that gets off your roadmap? But like, what do we think would be truly like the light your customers when it turns, when it comes to being able to do authorization?

Sam: And so those are kind of like two of the big problems that we help solve people take this piece of implementation work that your team would otherwise be spending, you know, potentially years on. And we do it for you as a service rate, but we, we kind of almost work as like a partner with a lot of customers, like a design partner with a lot of customers of like.

Sam: You know, okay, what, you know, what are your customers trying to do? And like, can we, can we leverage the patterns that we've seen to help guide you on like, making that not suck?

Corey: There, it feels like there's a Goldilocks story here, as in, um, if nothing else, t shirt sizing, you must be at least this tall to ride slash get value from Oso.

Corey: And I'm wondering, is there a, like, is there a sweet spot that you have for customer profiles around customer, about company size? Or company level complexity, I should say.

Sam: Yeah, there definitely is. Um, I mean, in the length of time, there's a thing we'll address where every single person under the sun should obviously use OSO, right?

Sam: Like, that's, we're a venture backed company, that's our mission, kind of thing. But it's true that like today, I think where we see our sweet spot is kind of two main categories of people. People who are maybe going up market, they're going after larger enterprises and they're realizing that they're getting like a ton of sales requests, like, Hey, to use your product, like we need to be able to segregate access within the market.

Sam: different teams or within different groups, right? Like we have sensitive data in, you know, this group of working on this other group shouldn't get access to. And like, we'll see this a lot of companies will start getting this request, right? It's no longer enough that you log in and you have access to this, the organization that that is sufficient.

Sam: We need to start getting things more granular, right? So like companies that hit that point with, you know, and it's, that's normally around like the size of customers they're going after. That's like a really good one.

Corey: No one is excited by the prospect of building permissions, except for the people at Oso.

Corey: With Oso's authorization as a service, you have building blocks for basic permissions patterns like RBAC, REBAC, ABAC, and the ability to extend to more fine grained authorization as your applications evolve. Build a centralized authorization service that helps your developers build and deploy new features quickly.

Corey: Check out Oso today at osohq. com. Again, that's O S O H Q dot com. When I wound up working at my first startup, I was their first non developer technical hire, which is always a weird place to find yourself in, but I wound up picking up a lot of good patterns that I carried with me forward from that. One of them was that when our auditors showed up, because we were in the payment space, they asked us like how they authenticated to the Wi Fi, it's like, oh great, the password is on the wall.

Corey: And they stared at me. Like, uh oh, that's not gonna be good, like, okay, so what, where's your active directory? Our what now? Like, I'm sorry, this is not a Windows shop. And they said, okay, let me distill this down for you in very simple terms. Once I'm on the Wi Fi, what does that grant me access to? And the answer was the internet and that printer over there.

Corey: They're like, wait, Okay, but from the office, you can wind up then getting special access into other things, like, no, that sounds like something an insane person might do. We wind up instead either using a VPN if we're trying to get into something sensitive, or, more commonly, every API endpoint is hardened, and we authenticate with signed requests on all of them.

Corey: And they're like, I've never seen that before. And it's, yeah, the reason we did it is because everything that did the traditional gateway stuff was really expensive and we'll, we'll see how this works out now. Apparently it's called Zero Trust or BeyondCorp and everyone pushes it as a best practice. And during the pandemic, we saw the VPN concentrators and a lot of enterprises started melting out of their racks when everyone used them at once.

Corey: But that was a. But it was sort of an interesting, almost by accident. It's easy to sit here and say, Oh, because I was a visionary. No, because I was cheap and didn't really know any better.

Sam: No, I see that pattern playing out a lot. It does remind me of like an interesting or important clarification I want to make, because I think probably I take this difference for granted, but it's probably not one that everybody does who's listening to this.

Sam: The kind of thing you're talking about is sort of internal company authorization, maybe like even like infrastructure or platform authorization, like within. You know, for us to be like, within Oso, what, what, what do I have access to? Like what, you know, AWS service can I access or like, which products can I access?

Sam: And, you know, which can I get to the email? Can I talk to the printer? Stuff like that. That's all like internal to the business. What can you get access to? The authorization that we typically focus on is for companies building B2B SaaS products, right? Like you're building a. And let's say GitHub, it's an example we use a lot, right?

Sam: You're, you're building GitHub. What authorization do you let your users do? Like how, how can, you know, how do people authorize and get access to things within the GitHub products, right? Like you can access GitHub organizations, you can maybe access certain repositories, I can set roles at different levels within an organization that means you can push to repositories or not.

Sam: Like, so for SaaS products like a GitHub, we're helping implement that kind of authorization within that product.

Corey: It's almost like you're skipping ahead in my notes as far as things I wanted to talk about, because this is exactly where we're headed with the conversation. Because one thing that AWS did, or Amazon did, in the early 2000s, which I thought was great, is Bezos passed, by decree, the idea that every company talks to each other via hardened APIs with the expectation that those things can become public at any time.

Corey: And that caused some great things, and some terrible things too. Like, it turns out when you holistically talking to each other as humans, You wind up with travesties like the billing system, but that's neither here nor there. The painful part, though, is that I think comes from a lot of cases where companies treat internal authorization versus customer authorization as very different things.

Corey: And there are times you can't escape it, but increasingly as I get older, that feels more and more like an anti pattern. I think it's because the idea that Once you wind up with a trusted network or a trusted inside group of people who are employees, you on some level wind up with a M& M style security.

Corey: You've hardened the perimeter and then you no longer feel the need to wind up defending anything inside of that perimeter. Now, in many cases, this is a good thing. There's a reason that Slack doesn't have a block button. It's because you, you, that's it. I've had enough. I never want to hear from those bastards in accounting ever again.

Corey: is all well and good, but you can't really have a functional business when that's the kind of thing that happens. Whereas I never want to hear from these people in public again who say mean things about me on the internet. Ahem. Ahem. Okay. That's a bit more understandable. For some reason, I've always had the impression that Treating employees as once you're in the in group you're in is a security misstep.

Sam: I think I understand. So you're saying like when you're building a product, like you're building, you're building something in GitHub, like you shouldn't, you shouldn't treat employees access to things within GitHub the same as external people access to GitHub.

Corey: Yes, now maybe there are permission groups that can only apply to people who have a GitHub employee flag set in their profile.

Corey: But the way they log in, the way that identity gets passed out, should absolutely not be a sidecar system. Now, yes, you need a break glass way for them to get access to things. If, if that identity system is what breaks, you'd better have a way to get in and fix that quickly. But as a standard operating procedure, yeah.

Corey: Going in the front door the way that your customers do, uh, first means you don't have to build and maintain separate systems for this that are going to diverge. And two, when there are customer side issues with this, you'll see them because they impact you as well.

Sam: Yeah, that's a really great point. And that one is a, I mean, just the reason people don't is like, it's hard to, it's really hard to implement that well.

Sam: Because to do so you need to have a authorization system that's like flexible to handle. You know, potentially suddenly users who can have access to like multiple accounts. And like, as we kind of spoke about right at the beginning, like the easiest thing to do is use hard code. Someone logs in and they only have access to the account they belong to.

Sam: If you now suddenly have like a support user who needs to go and like debug a customer account and they should get some limited access to that customer account. I'm just like, that's suddenly like undermined, like the entire way that you implement authorization inside your company. And like, it requires you like implementing all kinds of like hacks and workarounds to make that happen.

Sam: Something called, like, impersonation, right? The ability for, like, a customer support person to be able to, like, impersonate a user so they can kind of see what they would do and get access to some things that they would get access to. Doing that well basically requires you having, like, a lot of extra code to kind of, like, handle these different special cases.

Sam: And it ends up just doing, it just ends up being a different code path, just in a different way. Or you need to have like a very sort of powerful, generic, flexible authorization system that can treat, Hey, can this user access this other thing as a generic question, regardless of like how they get access to.

Sam: And so like, yes, 2D Moses porn, like we support that kind of situation, like really nicely. You treat all users the same. You can have a user with a global admin, super admin case, right? You're like, can I just say startup? And you say, yeah, I don't know. I said everything. You have a global super admin, they can access everything.

Sam: But like over time, you can implement things like, you know, support agent can get access to this customer's account. If the, you know, if there's an open support ticket for that customer and they've been assigned to it, right? Like you can start writing like very granular logic that where the sweet spot is or that like internal custom support person.

Sam: There's like zero friction to them seeing the things they need to see. Oh crap, I'm assigned a ticket, it's fine, I go to see that customer, I can see all the things. But they don't suddenly have access to like every company under the sun.

Corey: Yeah, that, that's where it gets weird.

Sam: Yeah, that's, that's where it gets, gets a bit concerning and strange, exactly.

Corey: And even in the areas of the, of the, uh, internal infrastructure where every employee has access to stuff, there are things you want to be very guarded about. Even my business partner, the CEO, does not have access to, uh, writable to any of the audit logs, for example. I do at the moment, but I, as far as I can, they're not mutable, but there are, I know ways around these things.

Corey: But again, I, I own the company. What am I going to do? Does I do this against myself? But there, there will be ways that we wind up sharding that in the future. Sometimes at clients, what I see is we go into optimize their AWS account, and there's a carve out, sometimes a separate organization, sometimes a series of accounts, because people with access to one are not allowed to touch the other, which great.

Corey: Awesome. Usually that's the security boundary, and you take a look at it, it's less than 10 percent of spend, so great, awesome, let them do what they're going to do, we'll work around them. I love seeing that pattern.

Sam: You know, and it reminds me, going back to the turtles analogy, I said authorizations are quite the bottom turtle.

Sam: The bottom turtle in my mind is lawyers. Because ultimately all of these technical approaches, right, at some point there's going to be some layer at which like you can't guarantee that nobody can ever do a thing. Generally at that point, that's where lawyers come in or auditors where you, you know, sign a document saying or a policy saying that I do not do these things.

Sam: And if I do, like, please hold me accountable to it. So, like, yeah, you're right. Like, at a certain point, you have to have, like, some boundary where somebody can break glass, do a thing, but generally, yeah, you write a policy, and you let lawyers enforce it.

Corey: One of our early, uh, attorneys, uh, who, uh, one of the first generals counsel we had here, was, uh, probably sort of better understanding of defense in depth than most, uh, security people I know, and his advice was very simple.

Corey: Uh, he's like, do not lose your shirt in business, Here are four things you do. Use them in this order. Step one, be a nice person. People don't want to sue their buddy. Two, have good contracts for when that breaks down. Step three, have insurance so that this covers these things when that turns against you.

Corey: And step four, have a legal entity so you don't lose your house when things completely go to custard. That's the shell. Use them in that order. And yeah, that's the way to think about these things. Because if you just go out there and say, Oh, we don't need contracts or insurance or legal entity because I'm a nice person and everyone likes me.

Corey: That's not going to work super well. Let me rephrase. That works super well until one day, all of a sudden, it very much does not. It's like, I don't think the house is going to burn down, but I have fire insurance on it. So one last question I have before we call this an episode for you, which is that I'm trying to understand what your adoption looks like.

Corey: I have to imagine you get no green field environments, because I have an idea I'm going to build something and see if it works. No one's thinking about security on the first step for that, unless it's a security company, in which case They think about security sooner than most, but still not soon enough to suit how most people think about these things.

Corey: There's always some means that people are using to authenticate and then validate that they have authorization to do things. How do you roll out in an environment where things are, I guess, Already pre existent.

Sam: So first of all, like, you'd be surprised. There are a lot of, there are a good amount of people who they start a company and they had so much pain from authorization previously and they knew that it's going to be important to them because they're in, yeah, security or health tech or fintech and they're like, you know what?

Sam: I want to get this out of the way before we do anything else because I've seen how bad it can be if you wait. Well, that does happen as well. But coming back to your, to your question though, like, you know, how do, how do people like it, maybe adopt this incrementally or migrate? Um, there's kind of a few parts to this.

Sam: So one, like what we often, what we often kind of help people do, um, is adopt this incrementally by like implementing the net new functionality they care about, right? So maybe it's, maybe they're migrating from monoliths to microservices and they want to start seeing like, how do I have an authorization microservice?

Sam: Like we'll help them do that part while maybe keeping the existing stuff running as it is. It might be a case of. You know, they've already got multiple services and they've, you know, they're, they're rolling out a new, a new service that requires a new functionality and some new capability. We'll say, okay, like, let's just implement it into that one new service.

Sam: Let's do that new stuff that you couldn't previously do that was going to take you, you know, have a long, you know, six months, 12 months in your roadmap to like roll out that new, you know, sharing capability before you had this new microservice. Like, we'll help you do that piece on one service so you can kind of see it.

Sam: See the patterns and then we can like gradually stop bringing over the old stuff over time.

Corey: I lied to you. I did have one more question I wanted to get into and I'm worried of how this might wind up shaking out. You recently wound up rolling out something called distributed authorization and the reason I'm nervous to talk about it is I'm concerned it might be some blockchain horseshit.

Sam: Well, yeah, no, don't worry. It's not,

Corey: would've been awkward otherwise.

Sam: Yeah. The cryptography and my PhD has zero to do with the log chain side of crypto, which is why I had to call it PhD in cryptography, not PhD in crypto, which makes me sad. But yeah, no, so dis distribute authorization, uh, it's, it's something we're pretty excited about because we've been kind of wanting to release it since the beginning of starting oso like four or five years ago of like how we think authorization should work.

Sam: It's called distributed authorization as a contrast to centralized authorization. So like historically, people, if they want to have some kind of like consistent way of doing authorization across the company, across multiple services, they put everything in a central microservice, um, all of the authorization logic, they put all the data that's necessary, which can often end up being like a lot of data, right?

Sam: It's, you know, all of the All of the user data and the roles they have, it's in all the resources you want to have access to, right? And in Google Cloud, right? It'd be all the projects and all the resources and all the projects they belong to, right? All of that data gets like shoved into this like central service and you have an API that says, can I use a do it thing or not?

Sam: That was kind of the old way. It was kind of painful because it really went against, you know, the, Microservice best practices of how you like you ideally want to kind of decouple and draw good boundaries between services. It had this like horrible coupling where you're synchronizing and sending all your data centrally.

Sam: But it was kind of the only way to get a consistent authorization implementation at like a large scale. What we've done with distributed authorization is we've basically made it possible for people to integrate a consistent authorization implementation into individual services while leveraging the data those services already have and own and manage.

Sam: Microsoft Mechanics www. microsoft. com So rather than going through this process of like synchronizing and sending all this data centrally, you can just like roll out authorization in one of those services, leveraging the data you already have.

Corey: Doesn't that dramatically increase the attack surface? You wind up effectively without the central source of truth that you are, that you are guarding on some level.

Corey: You, like, ignoring the split brain problems of distributed systems and in fact how you establish quorum. Uh, I guess you could read one Paxos for fun. Why not? You have a PhD in this sort of thing anyway. It'll be fine. No, what I'm trying to figure out is, does that mean that you have to be a lot more guarded as far as, uh, there's no longer a central, uh, I guess crown jewel area.

Corey: Suddenly everything becomes a theoretical tax point, doesn't it?

Sam: Not really. I mean, in, like, in the sense that with a central service, you can already, like, forget to call the API or just ignore what the API tells you. Like, you're already trusting that the services enforcing the authorization are actually going to check your service and do something with it.

Sam: Like, there's already that amount of trust here. I think, though, there is an interesting distinction, which is the, so the logic for who can do what in this world still lives inside that central authorization service. You have one place to look at the logic. You have one place to audit who could do what.

Sam: It's mostly just the data piece that is now being deferred to, like, handle inside the database. So, like, when I actually go and fetch a list of, kind of, servers that you have access to, based on projects it belongs to, that might just happen in the database that you have already built rather than inside the central service.

Sam: So there's, like, just a little bit of, like, weather processing happening that's different. And in both cases, you're still getting a full audit log of the authorization that took place. So we know, so right, like every, every time someone goes and makes an authorization call, or all the servers that I can, I can, I have access to, we'll audit log that that request took place.

Sam: Like who, what was the user, what they're trying to do, and what was the data that we would have gone and looked up to answer that question.

Corey: That makes sense. I have to imagine that's rather compelling for people who have bought into your vision of, of authorization.

Sam: Yeah, I mean, this, this feature came from a lot of, you know, feedback from customers who really, people really want this, like, I want to put authorization behind an API, I want to call that, I don't want my teams to go and re implement everything from scratch every single time.

Sam: That's the thing they're trying to get towards. But forever, like for a long time, it came with this like big cost of, okay, but to do that, you just go around to every single team and tell them, here's how to get the data into the service so that it can do those things for you. And so I think like removing that whole part of the conversation, I think is, is like pretty exciting for people.

Sam: They can now go to that team and be like, Hey, can We have taken care of that authorization thing for you. You don't need to think about permissioning and roles and groups and all that kind of stuff. We're just going to give you a library that you implement, client library and API that you're going to implement, like, integrate into your app, and you're good.

Sam: You're done. We've got it. We're going to audit things, we're going to review things, like, don't worry about that. You can just, like, carry on and do things happily. Which I think will really change how people think about adoption authorization.

Corey: I look forward to seeing how this winds up evolving. Thanks for taking the time to speak with me about it.

Corey: If people want to learn more, where's the best place for them to find you?

Sam: Yeah, well, so yeah, thank you for having me here. And, I mean, all this information is at osu. hp. com. Uh, from there, there's like a couple of paths you can go down. We have a ton of educational content for developers, like Authorization Academy.

Sam: Um, if any of this kind of, you know, if we went too fast, I know I speak pretty fast, you can kind of read that stuff in depth. You can go and just start trying out the OSO product for free. Like, you know, there's just this, you know, an unlimited free trial you can just sign up for and try out. That's awesome.

Sam: Uh, and we also have like a Slack community. If you want to like get into a bit more of a discussion and you're kind of thinking through some thoughts, but you have not talked about them, we've got a safe space for you to talk about authorization. So you can find all that from postHP. com.

Corey: And we will of course, put links to all of that in the show notes.

Corey: Thank you so much for taking the time out of your day to have this conversation with me. I, I really appreciate it. Sam Scott, CTO and co founder at Oso security. This promoted guest episode of Screaming in the Cloud has been brought to us by S. A. M. E. And I'm cloud economist, Corey Quinn. If you've enjoyed this podcast, please leave a five star review on your podcast platform of choice.

Corey: If you've hated this podcast, please leave a five star review on your podcast platform of choice, along with an angry, insulting comment that makes sure to start with the phrase, Don't you know who I am?