 June last year, and we donated that project to the Cloud Native Computing Foundation, which is an organization that owns a lot of the Cloud Native infrastructure, like Kubernetes, or Prometheus, or Istio, or a lot of the things that you may be using today in your as part of your application infrastructure. And we are the main contributors to that project. We spend most of our time working there. So if you go to the OpenFGA GitHub repository, you are going to see us working there. But we don't have any commercial offering on top of OpenFGA. You can use it, you can deploy it, you can operate it. And you know, if you have an open source project, what the most important thing for an open source project is to have stars in the repository. So if you go to openfga.dev now and you start the repository, I have like four OpenFGA hats that I'm going to give away for the first four people that do that. So hurry up. So in addition, on top of OpenFGA and also for OctFGA, we are building a lot of great tools to help developers use the product. On the context of a few things we're doing is we are doing an integration with Visual Studio Code that lets you manage and the language we have to define authorization models. The drag is going to explain later. That runs everywhere you can host Visual Studio Code, like in Visual Studio Code, or in GitHub.dev, or in VS Code.dev, everywhere. And it has things like validation and syntax coloring. We have SDKs for a few languages. We're going to keep building a few more. We're missing Ruby and Rust. And I think we're going to stop there for a while. And then we also have a CLI that you can use to operate the system completely. And drag is also going to show us that. On the OctFGA product, what we do is we take OpenFGA and we deploy it and operate it in a high-scale way, as we would expect of a company like OctFGA. So we deploy it in multiple regions. So if one region goes down, the traffic gets routed automatically to the other one. We can route traffic by proximity. So if you are calling us from a server that is close to a specific region, we are going to route your traffic that to minimize latency. We are targeting very low latency, so our target P99 is below 50 milliseconds. And we are getting lower than that. And latency is important because you're going to see when drag explains the product a little more, that you're going to call us very often from your applications. So you need very low latency. We are going to offer this in a multi-tenant environment like we call public cloud that we also have for our Octa CAC product. And we're also going to offer it in an isolated environment that we call private cloud, where you're going to be the only customer running in that environment. And we actually just finished a test where we could put a million RPS on the system, which is kind of a lot. And we added 100 billion tuples, which are relationships that was the data that we have in the system. So this is kind of very large scale, and we believe. And we can go higher, which is wanting to get there and go there. But we believe this product can scale very, very well. And then the other thing you're going to get, if you're using the hosted product, is we're going to make sure it's secure. The infrastructure is secure. The latest patches are available. That is compliant. That we're going to have enterprise support. We're going to be on call. So that's the difference between the open source product and the cloud product. And the other thing you get in the cloud product is a dashboard where you can create the models and manage the permissions. And also, it gives you a way to manage multiple FCA stores, which are the deployment units. And you can have one for development, for station, for production, or for multiple applications. And issue credentials for those. So now I'm going to let Raghett explain a little how the product works, and hopefully you get a good sense of it. Thanks, Andres. Hey, everyone. So you all heard Andres talk yesterday in the dev keynote. And you're all super excited. Like, what's this FJA thing? We're excited. You're excited. How do we start? There's multiple components before you can start integrating with FJA. In this session, we're going to focus on two, like the earliest two. First one is modeling. How do you model your permission system, your logic in FJA? The second one is how do you start integrating with the FJA APIs inside your service? So we're going to start with modeling. FJA needs at least two key data points to make a decision. One is the authorization model. The authorization model kind of represents the types or lists the types of objects in your system or resources. And what do we buy types of objects? That can mean anything. A user is a type, an organization, a document, a photo, a team. All of those are types of objects. Authorization model kind of specifies these types and how they could potentially relate to one another. Authorization models are fairly static. So they're not supposed to change daily. They change whenever you're releasing a new feature, whenever you're changing an enhancement. But more or less, they're fairly static. That brings us to our second data point that we need, which is your authorization data. The authorization data kind of reflects or represents the facts of your system. We call them relationship tuples. They are the things you know to be true. For example, if Henry created a document, you would send us a tuple that says, Henry is the creator of this document. It's our job to then use the authorization model, use the data to resolve your questions of what Henry can do. The authorization data obviously is going to be constantly updated. As your users are using the system, as they join organizations, leave organizations, start new projects, create documents, like photos, all of that you will be sending to us. Two key things. We only care about data that affects authorization. What someone's name is, we don't care. What the documents content is, we don't care. In fact, we really, really would like it if you don't send us any personally identifiable data, send you your IDs. We don't care about anything else. So we're going to start with actual modeling. What you see here is a very basic model. This is what we call the FGA DSL, or FGA Modeling Language. You always start with model schema 1.1. That's the only supported schema right now. It might change in the future. So our use case we're going to start with is, you have users and organizations. So fairly simple use case. So first thing you need to do is extract the types so that you can write the model. Users and organizations, fairly simple. You have a type that's a user, a type that's an organization. Okay, so far so good, I hope. Now let's think about how they could relate to one another. Generally, organizations have users as members. So we're just going to specify that. So under the organization type, we're going to say you have relations. You have, we're defining a member relation and then we're going to say, what does that mean? We're going to say you can see two square brackets and a user in between them. Whenever you see these two square brackets, it means this relation is assignable. That means you can write us a fact that says something is a member of an organization. And what the user there is doing is saying that that something must be of a user type. You cannot say an organization is a member of another organization. It has to be a user. So, okay. We're starting with modeling. Now we have a variety of tools to help you model. Andres showed the dashboard. We're going to show that soon. We also have the open FGA VS code extension and the open FGA CLI, which we're going to use to continue with this modeling session. So let's switch. Here is the lovely model you saw earlier. This is the VS code extension. Dot FGA is what the extension and the CLI read interpret to be an open FGA model. Just to show you, you can see the syntax highlighting. You can see validation. It helps you if you're doing any typos or anything that's not allowed in the FGA world, the VS code extension will help you notice and fix that. What you see on the right is a YAML file. It kind of represents your store. A store is the representation of your model and the data. In this case, you can see the model at the top that we're linking to this model. You can see the tuples. Tuples, again, your relationships, the facts of your system. Here we're specifying that AN is a member of the octa organization. So user AN is a member of octa organization. Notice, okay, there's user, relation member. Every tuple is in this format. You have to send these three points. When we say user, that does not mean a physical person. It doesn't have to be AN. A user is any entity. A folder can be a parent of a document. The user is a folder. So don't be mixed up with the name user. It's just, think of it as the subject, the principle. That's what the user is. So here we're saying user AN is a member of octa organization. Here we have a set of tests. We use that, like thing of these is your unit tests for the model to gain confidence that you're doing something and the model is functioning as you expect because this is kind of authorization, kind of important, you don't wanna make mistakes. So here what we're doing is we're saying, okay, when we finally do run a check, we expect AN to be a member of the organization and for FGA to return true. If Beth, according to the facts we have or the tuples we have, Beth is not a member of the organization and we expect this to return false. So let's use the FGA CLI to see so far. Is this functioning according to our expectations or not? So the FGA CLI does a bunch of stuff. We're gonna focus on the testing part here but it can do reads, writes, all sorts of things. So we're gonna test it and it's gonna tell us, okay, the two tests we have are passing as we expect. If let's say we said we expect this to be false, the CLI will complain and say, okay, no. One of the tests you wrote is actually not passing, you expected false, we got true. So in general, in a lot of B2B tasks, you don't just have a membered relation on the organizations. You have a set of roles maybe, you have a set of permissions. Let's expand them and say you have just two roles, admins and you have two permissions. Someone can invite members and someone can view the org. You'll notice a few new things here. First of all, they can view and can invite members no longer have these brackets. That means they're not assignable. You cannot say and can view directly. We'll tell you like this is invalid. It can only be inferred and this is what you see next. You can see this has another, now it's referencing another relation. So now if member is true, can view is true. Same for can invite members. You'll see another thing here, which is the org. If either the user is assigned or the admin relation is true, this becomes true. Our test is fairly simple. Ann is an admin of Okta. Beth is a member of Okta. What we're gonna test is Ann as an admin should be able to invite and view the org. So invite users and view the org. Beth being just a member should be able to view the org but not invite users. Charles, some other person should be able to do neither. Not related to the org. So less than the test. And it's passing as all the checks are passing as we expect. Now you can add a lot more, represent a lot more groupings. So let's say you have groups, teams, whatever. You'll notice this new syntax. Now it's not only users who can be assigned as admins. We have this thing that's called group member. Notice it's not group. So you cannot have a group be an admin. That makes no sense. It's group members. Members of a group can be admins of an org. And here, this helps because when you say group members can be members of a group, that's where you have infinite nesting. So you can do the same for orgs. You wanna nest orgs, an acquisition, fairly simple to model. And let's go through this quickly. Ann is a member of the IT admin group. The IT admin group members are members of the admin group. And the members of the admin group are admins on the octa organization. Beth is still a member. All the checks we ran in previously should still work. Even though we're not specifying Ann as a member, FGA understands and evaluates. Because of our model, this means that Ann is actually a member. And we ran the checks, and they should still all turn through. All are passing. OK. So we are done with representing our users and how they're grouped together. We're going to start going into resources. So I mentioned, again, resources can be anything. Documents, photos, likes, replies, threads, all that. What we're seeing here is we have a documentary source. And it has a creator. So each document has a creator. The documents are created within the context of an organization. So just that. And then we're saying, OK, who can edit a document, the creator, or the admin from the organization? And this is a new syntax you're going to see is the from. The from allows you to reference a different thing. So now you're looking at, OK, what's the organization? And get me all the admins from it. So any admin from the organization can now edit. Any member of the organization can now view. And because admins are members, then admins can also view. Over the test here, Ann is an admin. Beth is a member. Notice that we wrote two tuples here. So Ann created a document, the budget document. We had two facts. One, then Ann is the creator. Two, it's in the context of the octa-org. So that's fine. Sometimes an action can result in multiple tuples. That's not a bad thing. So Ann created the budget document. Beth created the roadmap document. Now Ann, being the admin, should be able to edit and view all the documents. Beth should be able only to edit the document that they created, but not be able to edit the document that Ann created, because Beth is only a member. Charles, not related to the org at all, should not be able to see or view or edit anything. So let's check it out. Again, everything's still passing. This is not the case when you're modeling. Sometimes things will fail, and you'll have to fix them. We're not going to go deeply into this. It's still the same logic. We just added a folder. Now you have folders. Folders can be nested inside folders, 50, 60 levels. You have documents inside folders. An editor of the top folder can read the document all the way down. It uses the exact same logic we've been using previously. We're also allowing folders and documents to be shared individually outside the organization. So you can share it with someone else. And here, what we're saying, I'm not going to go into this. Trust me, it's going to pass. And this basically kind of complex use case if you're going to do it in a proper authorization with what RBAC works fairly easily here. And OK. So we're telling you, OK, this is magic. This new FGA thing. It's based on RBAC, which is relationships. It works for all these use cases. Unfortunately, for some use cases that our customers and our users had, it doesn't work well. For example, when you want to do authorization and say that Anna is only able to edit documents starting with an S, or Johnny is able to view documents that are tagged, marketing, and published. So for those cases, they're possible to do in RBAC and in FGA. It just becomes a bit complex to think about and a bit harder. So we're working on this thing, which is bringing a bit of RBAC, not all of RBAC, into FGA, which we call it conditions. So now you're able to say, OK, I'm granting this user access for this specific time period. Or basically they have, in order for this tuple that I'm writing, this fact I'm writing, it's true within a certain condition. Here you can say, OK, we're saying, who can be viewers? It's users that pass this condition. And what is this condition? We're saying, this condition is a non-expired grant and a valid IP address. And it takes a bunch of input, like the current timestamp, what the timestamp that the grant was given, the grant duration, the current IP address, and what the allowed IP address range is. And you write the code, basically, to verify that. And in the tuples, what we say is, OK, Ann is a viewer of the document with the condition off, and then we provide context to that condition. What we're saying is, this was granted on this date. The grant duration is 10 seconds. And this is the IP address range in which this will be true. And later, when we're calling the check, again, in context, what we pass in is the current timestamp of the check and the user's current IP address. Basically, FGA will take these, along with this context, and try to evaluate this condition and only allow it if it evaluates it true. And again, here we see the viewer will return true. But if this is beyond 10 seconds, this will return false. This is outside the allowed IP address range. It will return false. Here we have checks for a list object. We won't get to them right now, but we also allow getting all the objects of a certain type that the user has access to. And basically, let's just run it. And, yeah, everything's still working as we expected. Okay, so now we've modeled. What do we do now? So here's another case where the CLI would help, is once you add your credentials and configure your API, you can just do write it, and boom, it's deployed. You're done. The CLI and the VS Code extension are also available on the web. So not the CLI, sorry, just the VS Code extension. So if you're in GitHub, your models are there, you can easily get into an editor. Your first time you need to install the OpenFGA extension, you get all the goodies, syntax highlighting, validation. This all still works. The CLI allows you to do ICD deployments. So here you can see, like, on this PR, it only passes if the model and the tests work, otherwise, like, reject it. And this helps you do, you wanna update your model, it has to go through SCICD phase. For those of you who prefer a less developer to ICD-centric way, we have the FGA dashboard which Andres pointed or alluded to earlier, which allows you to do the exact same thing we've been doing. It has same syntax highlighting, same validation. You can add tuples, you can run queries, you can see pretty graphs. And importantly, this is where you get issue credentials to be able to talk, to configure the CLI to the for deployment or the SDKs or your app. So this is the FGA dashboard. And this is where we move on from the modeling section to integration. So now we're modeled, we need to integrate with our APIs. Normally how we do that is, okay, let's say you have an API that returns documents, you have the route, authentication, and you throw an error on the authenticate fail and then you return it. All you need to do is add the part where you're creating the FGA client. And then before getting a document, adjust calling check. Write and check are two of the most important endpoints that FGA offers. Check is to check if someone has access, write is to tell us and update us with the facts. So get a document check first that they can access it and then only allow, return it if allowed. Same for write, in this case they're writing a document so inside an org, so check that they can. Like it was so earlier, Charles should not be able to create a document in the org he does not belong to. So check that they can, then create a document in your local database, then update us with the tuples to stay the fact that this thing has just happened. Sharing extremely easy. So you wanna share documents, check the user can share it. Yes, all right, let's share it. Write the tuple and you can share it and that's it. You can either make it with a middleware, so now things you can take the logic a bit up higher so now it's get, authenticate, authorize and continue on with your life. Again, for updating, for deleting, we're not going to demo. Andreas talked earlier about our timeline. We had an early developer community preview. We had a private beta in March at 22. We open sourced it in, we open sourced open FGA in June 2022 mainly because this is something we wanna collaborate, we want it to be more out in the open. So we'd love your contributions. You know, mistakes on our docs or SDKs are not working as you expect. You want more features? Feel free, don't just star us, feel free to contribute or talk to us and we'll work through it. We released the limited early access earlier this year and as Andreas said, journal availability next year. You can already sign up, so the developer community preview is still running. You can sign up for free on the dashboard, use it just with a bit lower rate limits. Resources, open FGA, check out the website. OctaFGA, again, check out the website, they link to a bunch of resources. A quickly documentation of FGA, the dashboard and the developer lab, if you wanna just have a, it basically talks about what we talked about earlier about how to model. And there's a getting started guide in the documentation that's also really helpful. Please connect with us. OctaFGA, we have a vibrant community on the Azure Labs Discord community. Join us, do ask questions. Nothing's not allowed, well, some things are not allowed. Be respectful, please. But do talk to us about FGA. Open FGA also has a vibrant community. Join us on GitHub, follow us on Twitter and thank you, thank you so much. I hope this was informative at least, hopefully interesting. If you wanna ask us questions, Andres and I will be outside. We look forward. And thank you, hope you enjoy Octane. Thank you.