Chapters
Shownotes Transcript
Hey everyone and welcome to a Risky Biz News sponsor interview. I'm Adam Boileau. Our sponsor this week is Okta. Most people know Okta as a company to which you can outsource your authentication complexity, but they're working on giving developers a way to give authorization the same treatment. I'm joined by Cassio Sempaio, who's Chief Product Officer for Customer Identity at Okta. I started by asking him why authorization is the next step for Okta.
The authorization problem may be where authentication was maybe 10, 15 years ago, where the problem was becoming well-formed for a technology to deliver that as a service to anybody who needs it. We think authorization is there right now. And the way we're thinking about the authorization problem is that managing authorization logic is really hard because it's embedded in the application. So if you're an enterprise and you have 600 apps,
you may have 600 different authorization models embedded into
I'm exaggerating a little bit, of course, but you could have in an extreme case hundreds of different authorization models, every developer is embedding them into their own application, which is not only a potential compliance, auditing and security nightmare, but it's also very hard to manage just from how you run your architecture, how you run your infrastructure, and how you ensure that those services are provided in a secure and effective way.
So based on that hypothesis, we deal with the service that we call fine-grain authorization that delivers low-latency, high-performance, global authorization on a centralized manner for any application that needs that type of service. Is this a thing that's been done before or is this new? No, it has been tried before.
And it's fascinating because by talking to industry analysts and others that have been in identity space for some time, you hear this a lot. People say, oh, you're going to try authorization. You're going to find a lot of corpses like in that space. But we believe that there's a few things that are different.
right now, one of the many, but maybe the most important ones are the awareness of how critical authorization is in a world of increasing security risks. We're looking at some of the data, three of the top 10 OWASP IPI security risks are related to authorization. Users end up with more permissions than what they need, able to view resource and attributes that they shouldn't. That's one.
Second, there's a lot of apps out there, right? There's more apps out there than have ever been before. So you just have much more of a surface area for the authorization problem to be meaningful. But third, the cloud computing technology maybe wasn't ready six, seven years ago for this because to deliver authorization at the scale
that enterprises need. We are talking about sort of that 20-ish millisecond range, potentially 100 times more authorization requests that don't have fair authentication and done globally. And cloud computing wasn't quite there like six, seven years ago, but now it is. So I think the confluence of those factors makes this possible now.
So I think in my penetration testing career, in the early days, it was about bugs in applications. You'd show up, you'd find a vulnerable component that would give you, you know, command execution or, you know, Instagram file upload or something like that, and you would compromise the systems. As we moved on, a lot of the bugs we found stopped being, you know, straight up bugs in frameworks or applications and started being the business logic of the application doesn't match what the user expects.
And most of the time we would not get from a customer, here is a statement of what our expectations are. Like I expect a person who can comment on an issue on GitHub can't close an issue on GitHub. Or if we're looking at complicated business applications where we can't infer the rules or guess them, the idea of having a framework where those rules are expressed properly
kind of semantically, like in a way that we can read and make sense of and infer the intent, that seems like to your point that the cloud wasn't ready. I also don't know that developers and security testers were ready for a world where that kind of logic wasn't just embedded in applications. So can you explain, like when someone is developing an application, how do they express that?
the authorization rules that they're trying to implement in a system like this? Yeah, this is, no, that's a great, it's a great question. So we are following the, Google published a paper that then became quite popular a few years back. It's called the Zanzibar paper, which is essentially saying
It's not a spec, it's not a reference implementation, but it's essentially a paper that talks about their own experience on how they made essentially Google Docs possible. Because the problem with Google Docs is a very interesting one. Most authorization problems of the past were about, "Adam, I'll give you permission to this specific capability on this application." You get to edit the customer record.
But the Google Drive, the Google Doc problem made that like, no, the objects are dynamic. I can create 100 docs a day. I can share some of them with you. I can share some of them with a group that you're part of. It really makes the authorization problem dynamic and much more complex.
So what we are doing with our technology is using the Zazibar model, which is a relationship-based model for describing essentially how your organization works, what are the objects that your organization care and share and need to give permissions to different individuals.
allows it to map if those individuals are parts of groups, parts of departments, parts of any logical construct that they belong. So all the data sits in that repository that's within our technology, and we expose that to the application via a very simple API. So you're essentially going to hit that API with a specific request, and you're just going to get yay or nay responses in a very streamlined basis.
So that's a simple use case for that. There's one that is in my mind right now that I think would be useful, which I guess takes it to the level of complexity where it gets very interesting. And we implemented something like that ourselves too. When you think of an authorization problem where you only want support engineers to have access to the data of a specific customer that has an active support case assigned to them.
It's a pretty complicated problem because it depends, is that open or not? Is my CRM, where do I pull all of the data? This is the type of thing that the fine grant authorization can really make it simple because it brings all of the data in.
And then the support app can just say, "Can I or not like to look at this customer data?" And you basically get an answer within a couple of tens of milliseconds. Yeah. When I was reading, I read the Google Zanzibar paper as a bit of background for this, and I was struck by my background is in Unix stuff. And we turned very, very simple Unix file system permissions into
into a, you know, quite a complicated system where we would, you know, overload what the execute bit bends in a different context, or we would assume that write to a file implied something about apps because apps store data and files. And now that data is not files anymore and we have complicated cloud systems, like that old way of thinking about authorization and, and
One of the things I really liked about Unix file system permissions is it's straightforward to audit. You can read them and assuming you understand the relationship between what the bits mean and what they mean in this particular context, like if you're looking at applications that store data and files, what that means in that context. But we are very far beyond that and having a system where
you can see those rules expressed to me as a security practitioner sounds like a wonderful, a wonderful, beautiful future where we can actually see that logic expressed independent from the application. So the like, have you developed tools that audit this access or consume the logs from these kinds of authorizations to provide much better visibility as to what's going on in applications?
That's exactly around the vision for the product today. So of course, with the existing version of the product, we will stream all of the real-time logs from every request that's coming in. Of course, the response like denied or not for those requests. But what we are working on right now is along the lines of what you're saying.
You'll see it. Of course, people love to say the data is the new oil. So I'm not going to say that. But the idea that we have
every single data, every single bit of data, every single request that has hit our system, it becomes relatively simple for the system to say or to infer that a specific class of requests just should not be happening. Because historically, why suddenly I'm seeing an influx of requests for access for this specific object from a group that's just like
has never had this kind of characteristic or this range of transactions. This time of the day, from this specific location, and you keep looking at those different attributes, we use something like this already. We call it Okta AI on our bot detection, adaptive MFA, some other areas of the authentication product, trying to bring that into the authorization domain right now where we believe there's actually more scope
for the accuracy and the quality of those algorithms just because of the sheer volume of data. We have a few prospects right now. This product has been live for a little bit. We have a few live customers and some of the prospects that are very large, they have in the order of like 100 billion plus relationships that need to be modeled.
That's incredible, right? That kind of data, once you start to see the flood of requests that will be coming in, there's a lot that you can infer in terms of security profile of those transactions. Yeah, it seems that you get a lot of insight into what's going on on the inside of an application that just say, looking at
log in, log out, doesn't really get you, right? You get some actual visibility into what's happening inside the app, which gives you scope that my mind is glowing just thinking about what you'd be able to do with that data from a detection point of view and also from an understanding impact point of view, like one of the really hard parts of
we see as people get compromised and then having to figure out what an actor did in your environment in this case if you've got a compromised user identity or a user session
understanding what then the authorization system gave them access to. That sounds super valuable for incident response and understanding the impact in the cloud environment. So this is for developers to use when building applications as opposed to something you would retrofit this into existing stuff. This is for new build applications? Yeah, that's a great, really good question. What we are seeing right now
with customers is that customers are looking for a new app that they are building or an app they are refactoring or something they are lifting from the old world to the cloud or something like that as an opportunity to bring this technology in.
and ease their way to understand how the technology works and eventually move to onboard their legacy stacks, the legacy apps into this. The complexity, as I'm sure is on your mind right now, and I'm saying these things, is that in some cases you're talking about an open heart surgery to applications that maybe have decades of legacy in there.
some of those applications like you, nobody's very excited to go back to them and work on them. But what we are seeing is in every organization, the rate in which digital transformation is driving new projects, new transitions, there's always something, there's always an opportunity for someone to pick it up,
tests like in that and make that the standard moving forward. And then, of course, over the years, we expect that customers will be migrating like over. And of course, that knowledge will help us understand how to simplify that. Like we have a culture here at Customer Identity at Okta have a pretty comprehensive set of SDKs to meet customers like in their different programming languages, give them a sample code, give them a really quick way to get started. And we're doing that for FGA, too.
Yeah, I had a quick look at the FTA dev sandbox thing, which if you are a listener who's interested in this kind of thing, you can choose a couple of example applications that you're probably already familiar with, like GitHub or Slack or Google Docs, and see how that's expressed in this kind of relationship-modeled way.
Authorization language. And I found that very helpful to understand, you know, what you're trying to do, but also having, you know, visualizations of the paths that a query takes through the graph to answer these questions. I really liked that as a way to explain to developers kind of how this works. And I imagine that, you know, every developer you've ever talked to probably says, oh, hell yeah, please.
Like, is this a thing that you have trouble explaining to the business? Or is this the thing that the obvious auditability and visibility benefits just sell itself? We find very polarized audiences. Like, if you will, you have that kind of developer that immediately like rocks the concept, like, yes.
This is it. Relationship based. I just have to make sure that I don't build an impossible to like traverse like graph like there. Like and then I'm good. And then you get the other camp where it's like, oh, OK, tell me everything about it because it's not intuitive. It's not something like authentication is so obvious. Yes, you need to access the app.
Since the days of the remote mainframe terminal, people have seen username and password in there. But authorization is not like that. It's like beneath the surface, if you will. So the reason why we built fga.dev, we also open sourced FGA. We have OpenFGA that we donated to the Cloud Native Computer Foundation, to the CNCF.
with that intent too, to drive more awareness and also to pull all the experts, pull people that really care about this problem into helping us develop this. There's a lot of challenges there, like in sort of bringing the industry together, coalesce behind this problem as being a big part of why we're doing this. Because I mean, when I first read about this as an Okta product, my first thought was, well, how does this work for vendor lock-in, right? If you're developing an application and you're
this kind of model you know where you're calling out to a third party to provide such a critical part of your app like is this a thing developers going to be reluctant about because you know they're afraid of lock-in but the fact that it's kind of open source that you're building a standardized kind of approach where you could run it yourself on-prem like you could run your own instance of a you know a system to resolve these queries is that a thing that that was kind of part of that choice?
We spent a good quarter reflecting on the open source decision, but the key drivers for that, beyond what I said around community, around bringing the experts around, the point that you made is that there is a way, given an open source version, there's a way for folks to experiment by themselves in the safety of their own environments, either on-prem or in cloud computing.
Certainly, it's made me think about a few things that I've built over the years and think, damn, I wish I had one of these when I was thinking about authorization problems. Anyway, thank you very much for your time, Cassio. It's been a pleasure to talk to you and I look forward to seeing this being used by customers. That's great. Thanks for having me today, Adam.
