Guest: Or Weis (LinkedIn, Twitter)
Company: Permit.io (Twitter)
Show: Let’s Talk
Keyword: Identity Access Management (IAM)

Permit.io is a startup that provides a full-stack authorization framework that aims to help developers build permissions systems into their products easily and efficiently. Spending time on access control can be a huge pain point for developers taking time away from building the actual product and requiring a lot of skill sets that some developers may not have.

“Building permissions and access control yourself is going to take you a lot longer and will require a lot of skill sets that you often won’t have,” says Or Weis, CEO and Co-Founder of Permit.io. “It’s really not something developers want to do.”

Permit.io frees developers from working on these challenging tasks and “focus on what they actually care about or what they are  passionate about and the core values of their product.”

Weis explains how he found it frustrating as a developer constantly having to build access control solutions for his products from scratch. He felt that just as you don‘t have to build authentication from scratch each time, neither should you have to for permissions or access control.

One of the increasingly problematic challenges for a developer has been the growth in microservices and having to have access control in each microservice. As Or Weis explains, with every microservice having on average three authorization queries or permission queries per request that it’s handling, the problem has become a lot more complex to manage. Permit.io looks to offer a solution for those challenges.

Another potential problem is in the process of authentication solutions checking against the identity management to verify that the person or the entity connecting is who they say they are. With developers often left to decide what that user can do and what permissions they should have, unfortunately, this can lead to a lot of work and the potential to make mistakes. With Permit.io, once you’ve adopted your authentication solution and have worked with the customer’s identity management, you can seamlessly manage everything in your product.

Permit.io was originally built on top of an Open Source project, OPAL, which aims to give developers all of the infrastructure and tools they need to manage authorization. Or Weis explains that an important part of the project was being able to share it with the developer community. Although it is still a new project, it’s already been adopted by Tesla, Accenture, and Zephyr.

Highlights of the show:

• What led to the creation of the company?
• How difficult is it to build permissions, especially in the cloud?
• How is permissions related to Identity Access Management (IAM)?
• Why should someone use Permit.io instead of building permissions themselves?
• What is open source project OPAL all about? How is Permit.io leveraging the project?

About Or Weis: Or is the CEO and co-founder of Permit.io, and co-maintainer and author of open source OPAL.ac. Or is a serial entrepreneur who is passionate about developer tools, previously founding Rookout.com.

About Permit.io: Permit.io enables developers to bake in permissions and access-control into any product in minutes. Open source at its core, the platform builds on top of OPA+OPAL as a service, providing the API and UI access-control interfaces that make it simple to shift security left. Permit.io is founded by former engineers from Facebook, Microsoft, and Rookout and is already used by industry leaders like Tesla, Cisco, Accenture, and others.

The summary of the show is written by Emily Nicholls.

Here is the full, unedited transcript of the show:

• Swapnil Bhartiya: Hi, this is your host Swapnil Bhartiya and welcome to TFiR Let’s Talk. And today we have with us Or Weis, CEO and co-founder of Permit.io. Or, it’s good to have you on the show.

Or Weis: I’m excited to be here. Thanks for having me.

• Swapnil Bhartiya: Yeah, it is my pleasure to have you here. Let’s start with some of the basics, which is, since you are also co-founder of the company, what specific problem did you see in this space that you wanted to solve, that you created the company?

Or Weis: Both my co-founder and I come from a developer background, and throughout our careers, we found that we constantly have been building access control solutions for our products, always from scratch and more often, more than once. So for example, with my previous company, Lookout, I ended up rebuilding access control five times. I said, “That’s probably four times, if not five times too much.” And that pain point of constantly having to build access control, was just annoying, and we wanted to get that off the table. Just like you don’t build authentication from zero, just like you don’t build databases or building from scratch. There’s no reason why you even have to build permissions or access control. So that’s what we bring out of the box, so people can focus on building their own products.

• Swapnil Bhartiya: Or, just stick to permissions, how difficult it is to build permissions, especially in the cloud.

Or Weis: So it used to be somewhat easier when we’re working on mono lists. So you had one core spot where we would integrate your access control and a lot of frameworks like Django and Spring Framework would come with something ready made that you can use. But as we move to microservices, now we found ourselves having a bit of access control in every little microservice. On average, every microservice does three authorization queries or permission queries per request that it’s handling. So that already made the problem a lot bigger, a lot more spread out, and in addition, the complexity of the applications themselves, the products that we are building are constantly requiring more capabilities. So everyone starts with just let’s have an admin and not admin. We, the developers would be admins and everyone else won’t be, but then you quickly find that you need role based access control, and then role based with ownership and then attribute based access control.

Then you also need audit logs and you need impersonation, and you need invites, and you need approval flows, and you need more and more and more constant demands are coming from upper developers, from security, product, compliance all over the board. Every time it often requires you to go back to square one and rebuild your solution. Combining that with the growth of this tax stack itself with microservices just creates a huge pain point. A lot of times maybe the most difficult part is people are not aware of this. You initially think, “Oh, this is going to be easy.” And then half a year later, you discover how much effort you have actually put in, and that you’re still not done.

• Swapnil Bhartiya: When we talk about permission, it is very closely related to, of course IAM or Identity Access Management. Can you talk about, especially from Permit.io’s perspective, how it’s related? You also talked about the previous companies that you’re involved with. So let’s understand that relationship as well.

Or Weis: Permissions or authorization is part of the bigger space of IAM, Identity Access Management. IAM is what I like to describe as a waterfall. It starts with identity management, so solutions like Okta and Azure Active Directory, they’re responsible for just managing for the organization, which identities they have and what kind of attributes or information we have about them. So for example, we can say we have Danny and he’s part of the marketing department, and he works Friday to Sunday, only the afternoons. For some reason, he has a very good comfy position, and he’s working from California. So that would be something that would be managed by the identity management. Down the road, when you start connecting products, that’s where the next tier in the IAM stack comes in, and that’s authentication. With solutions like Auth0 and AWS Cognito and OneLogin, and a bunch of others, especially a bunch of new others around the password list space.

Either way authentication solutions are responsible to check against the identity management and to verify that the person connecting or the entity connecting is who they say they are. Once they’re verified, that goes into the product itself, into the application. That’s where permissions and authorization comes in. Once we know who they are, we need to decide what they’re allowed to do. So for example, you’ll have a bouncer in the beginning at the entrance to a building, but once they’re in the building, which rooms are they allowed to go? Which companies are they allowed to interact with? So that would be the difference between authentication and authorization, which a lot of times people confuse, mostly because they sound the same. Up till now when we’re using IAM solutions, they would mostly give you identity management and authentication. The authentication part will include claims, things like, “This user has an organizational role, they belong to the marketing department.”

Something that the application can use to make decisions on what they can do. But those decisions, were left to the developers themselves. They were left to proprietary code for each application. That leaves a lot of room for, A, a lot of work to do, and also a lot of mistakes, because just like authentication, there’s a lot of photography and security challenges that require a lot of in depth experience to do. That’s where we come in. Once you’ve adopted your authentication solution and you work with your customer’s identity management, you want to manage everything in your product or products and you want this to be seamless, you want this to be powerful enough so you can define all the policies that you want. It should work seamlessly with the entire stack that you already have in place. That’s what we provide for developers and for the other stakeholders with low-code no-code interfaces.

• Swapnil Bhartiya: Can you also talk about the challenges that might be there, whether you talk about authentication or authorization in the multicloud world, where sometime IMs are tied to a particular cloud provider. You can have AWS as its own, Azure or [inaudible 00:06:53], how do you deal with that? How challenging is it? How do you deal with that [inaudible 00:06:57] problem?

Or Weis: So luckily for us… It’s actually the reverse, because we understood that the space is mature enough and that part is specifically not a problem, we were able to recognize the opportunity here and start Permit.io as a company. What really enables this is standards that have come into maturity and the main one is JSON Web Tokens. So basically every authentication provider today can provide you a standardized way to interact with it without requiring a proprietary protocol.

Every authentication provider can create a cryptographically signed certificate in the form of a JSON Web Token and passes along to the product or the authorization layer. We can latch onto that seamlessly. You can just pass it directly to us as part of our APIs. And then we don’t really need to care what’s up the stack from us, which authentication solution is it, how it connected to the identity management solution. That’s basically transparent. Also, it enables us to work with whatever stack each customer chooses and it can also be multiple solutions per customer. It’s thanks to those standards that we can take this forward, and we’re also excited about creating more standards down the stack. Now that we’re building authorization in an organized way as a unified product with unified interfaces, we’re eager to create a standard that the rest of the ecosystem can connect to as well.

• Swapnil Bhartiya: You did touch upon that earlier, but this is an opportunity for you to talk about why someone should use Permit instead of… When I say Permit, the name is interesting Permit.io instead of building permissions themselves?

Or Weis: Well, the main reason is, it will take you a lot longer and will require a lot of skill sets that you often won’t have. That’s the main premise, but I think the main thing is that it’s really not something you want to do. When you talk to developers, they often don’t care about access control. It’s a requirement that they have to tackle that a lot of stakeholders are requiring from them, but it’s not the focus of their actual product. It’s almost exactly the same across every product, so you see user management with roles and you see API key managements and secret management and audit logs and impersonation and approval flows.

These are not unique to any product and yet you end up building them, and when you build them, you’re not even excited about them. The main reason here is just to be able to focus on what you actually care about or what you’re passionate about and the core values of your product. So instead of building something that you probably already built somewhere else and something that other companies have built a billion times, focus on the important stuff. That’s I think the most important part of it and also on the way, automatically adopt best practices, avoid vulnerabilities, build it in a way that is future proof and don’t fall into annoying pitfalls.

• Swapnil Bhartiya: Now I want to talk about the Open Source angle as well. You are a founder of OPAL Project. Talk about that project, and also how is Permit leveraging it?

Or Weis: As developers ourselves, we were really excited about Open Source. We really think that’s the way to build the conversation and create those standards that I’ve mentioned before. We started, first of all, adopting the existing Open Source project. We started with OPA, Open Policy Agent, which is a general purpose decision engine and we found OPA to be a great engine, but it was really geared towards working in Kubernetes and infrastructure level authorization. We wanted to take it to application level permissions. So we needed a way to sync it with the changing tides and data stacks of the application itself. I’ll give an example for what I mean. Let’s say you want a very simple policy [inaudible 00:11:09]. Only users that have paid for a feature can use it. That bit of information who paid for the feature no longer resides in your apps database.

It now resides in a third party service like Stripe or PayPal. When someone swipes their credit card, you want them to gain access immediately. So we need a way to constantly keep the authorization there in sync, in what’s happening in the application and all of its dependencies. That’s where OPAL comes in. OPAL creates a live real time, pops up channel, that updates Open Policy Agent on the fly. So when an event comes in from wherever you want, from Stripe, OPAL can listen to it and tell each of its clients to go and fetch that data and that way be synchronized and consistent with the state, so when an actual authorization query comes in, they give the right answer. There’s a lot more that OPAL actually does, and a lot of minute details in the implementation of how you do consistency, and how you connect this to Kafka and other solutions like that, but that’s the core concept.

We built OPAL because we had to. We wanted to build Permit.io and OPAL was one of the key building blocks that we had to build. We decided that critical element should become a standard and we should share it with their rest of the community. The minute we’ve built it and we were happy with what we created, we took it Open Source and we were really excited to see how much of love it got so early on. It’s still a young project. It’s only half a year, seven months old, but it’s already being adopted and is in production in amazing companies like Tesla, Accenture, Zephyr and other awesome places, and this trend is only continuing.

Once we had that maturity with OPAL, we were also able to build Permit.io, which leverages both OPA and OPAL within their good infrastructure and adds on top both APIs and experiences for your internal stakeholders, product security compliance, but also your end customers. The idea with Permit.io is you get a end to end experience unless you want to build something, you don’t have to build it. And when you want to build it, you can always go down to the Open Source building blocks. So you are never locked in to something that you can lose control for, because we hated that concept as developers. We wanted to bring it to our customers as well.

• Swapnil Bhartiya: Or, thank you so much for taking time out today and talk about the company. Of course, good luck, best wishes for the success of the company. You have big plans there. Thanks for your time today, and I would love to have you back on the show, because this is a topic we’ll be talking about a lot in coming in our time, so thank you.

Or Weis: This was really great to talk with you. Really great questions and I’d be happy to come again. Thank you very much. It was a pleasure.