Alright, so as Gustav said, we're gonna talk a little about a different aspect of policy in this session. So Graham, did I set up for authorization? I tend to avoid their term feedback, so I'll say that only once here. And then also Gustav gave a little bit of a talk about some happenings in the market and his experiences. So what we have not focused much on, although talking a lot about authorization at the conference, is interoperability between these different policy formats to the gentleman's question that was just asked. So that's why we're going to be talking about ID QL and HEXA and how that fits into the, the story here.
So if we just take a step back for a moment and look at identity standards, there's a lot of them in existence over long period of time. Things like SAML and maybe some of you remember Liberty Alliance id ff Identity Federation framework. I see some nodding sholis and then yon to and open ID connect and they have given us a a certain level of interoperability among identity domains. What about on the policy side? So we have lots of different ways or different ways of describing authorization, externalized dynamic attribute based, fine grained, even modern. I think we have a session come up that's something called modern authorization, but what about interoperability between these policy formats? We don't talk a lot about interoperability when it comes to authorization unless you're talking about the exact standard. I happened to organize the first ever interoperability demonstration of the exact, I think it was exact exact 2.0 format sometime ago.
And in that example we were focusing on if a vendor created an example policy and their product, could we take that XML file and load it into another vendor's P D P and get the same result when we sent it a request. So that was a quite an interesting exercise. Fast forward a few years now with the J S O N profile for Exacto 3.0. Basically any client can send a JSON message to an EXACTO PDP and get a permit or deny response back. So we have some level of interoperability at least within the EXACTO standard. But what about across all of the different vendors or formats that Gustav alluded to a few moments ago? So that's why we've embarked on this journey to create identity QL or I D L and the HEXA open source software project in a way to standardize the format of policies and be able to translate them to and from formats across cloud environments and across the stack.
So this is largely driven by a multi-cloud world. There's another Analyst firm that that says the vast majority of enterprises use two or more cloud platforms, some many more than two. So you have multiple identity, you have a multi-cloud environment. That also means you have multi policy formats cuz each of these major cloud providers and as well as you know the second tier of growing cloud platforms, they use their own policy models and their own way of managing that access within those platforms. This also exists up and down the stack that the application, the infrastructure, the data network, it all has the same issue. And then of course we still have on-premises apps and legacy apps to deal with. So indeed quite complex and quite fragmented. And it's not just us at strata that came up with this idea. We talk to quite a lot of customers and these are some example quotes that they come up with that I, that I captured.
And so you can see we want to have a common policy set that is independent of the target system. The second one is slightly different, but they wanted a single way to author policies and be able to translate and distribute to the various runtime systems that they might have in place. And the third one is another slight twist here. They also wanted a common way to express policy and that they felt that was a huge gap in the industry. So we embarked and said, well let's define a common declarative model. No invention here. This is not brand new, it's it is just a five tuple model subject action resource or object within a set of conditions or within certain scope. So the idea is that we can define many different types of policies for different use cases or industries for different compliance regimes and cover a lot of different capabilities here.
And then from here, we didn't just define the schema or the format for the I D Q L policy, we also built an open source reference implementation. So this we call the HEXA policy orchestrator and just, we don't give you only slideware today, I'll be able to show you a couple of demonstrations of how we actually do this. And we felt that was important because anyone can define a spec and you'll publish it. But how do you show that it actually works? How can we encourage a adoption in collaboration? So the policy orchestrator can take the ID QL as input, it's just JSON formatted to file and connect with systems that it has integrations with and do things like Discovery Connect, see what applications are there, what other resources, what policies exist, pull that in. Now I can translate it to ID ql, I can make changes there, I can manage it in that format, push it back out in reverse, translate it back and orchestrate it and activate it in those platforms.
So now you can imagine if I am connected to many different target systems and platforms, I now have a whole catalog of policies in one format. I can do governance at stations, certifications, reviews, reporting and so on, which is very difficult to do today. Digging a little bit deeper e this is the architecture of the policy orchestrator, which is mostly in the middle there. And so we have arrest API where an program or UI can call it with a managing idq files. And then there's three main provider functions here and that is the discover get and set policy. And then a little bit to the right, you see this column that has different provider packages. So this is where the details of the mapping or the translation take place to the individual target systems. What's also interesting to point out here is that we are connecting to publicly available APIs for these systems.
So if your, if your cloud platform or application or service has an API for configuring policy or users and what have you, that's the API we're using. So we don't have to wait for product managers within these services to put ID QL on their backlog. We can bring the standard to them, which is quite different from when you know things like SAML were first introduced back in the early two thousands. Alright, so there so far in our work on HEXA we have come up with three different ways of mapping policies. Of course we're, we're dealing with a very diverse set of formats and, and in some cases standards.
So we can do it by API call. This is probably the most simple for course green models that are maybe group or role-based. So we can call that API and map the group a role from the idq QL format itself. The second one here is a little more complex but sometimes more clean cuz we can in some cases translate from ID QL to a policy language and we give two examples here. Google bind to, it's also known as Google's common expression language or the new Amazon web services Cedar language. So we can directly translate one to the other. And the third one is very interesting and it corresponds a little bit with what Gustav was just talking about and and his experiences with open policy agent. So we have a model where you can directly interpret i d QL by the target platform. In this case we leverage the OPA capability to consume a J S O data file. In our case that data file is I D Q L policy. Very interesting way to leverage that capability. So in my demo I will show you the the latter two examples here. Alright, I think that's mostly it for the slides.
What I do first is give you a bit of a tour of the websites and information from that perspective before jumping into a couple of the demo scenarios. So let me fix something here so I can see. So I didn't point out yet, but the project is a cncf, a cloud native sandbox project. So this is also the home of open policy agent by the way Kubernetes. And if you go to the CNCF webpage and scroll down, you'll find HEXA here. And then a link to the project website, which is this, I'm sorry, which is this site here shows you more information. There's a link to the GitHub repository as well as a sign up form, excuse me, to join the working group. And if we go to the repo now there are two main repositories within GitHub, the policy orchestrator, which is the HEXA software and then the policy repos repository, which is where the I D Q L spec is defined.
So if we just first go for a moment into the orchestrator, what you can do here is you can download the source code and you can run the OPA example that I'll be showing you in just a moment. So if you go to the Read Me, it has some simple instructions of how to do this, you just need go docker and pack all free software so it doesn't cost you anything. And then you'll end up with a set of applications running in a docker instead of containers. And on your desktop it'll look like this. So you'll get HEXA admin, which is a simple UI that you'll see in a moment. We send you an Opus server so you don't have to download and configure that. The orchestrator is the main software here doing translation and such. We have a demo application that you'll see the demo config. This is where the opus server gets its policy bundle and then there's a a database as well.
So that's a tour of that. Let's go back to the slides. So the first demo is integration with opa. As I said, what you'll see me do is open a set of policies in a policy bundle. I'll make, I'll, I'll make some change to that, show you in the demo application how the changes take effect where, where the policies look like today, we'll make a change to that and rebuild that bundle and we'll see the change in the application. And this is what it looks like. So you'll see what I'm doing in the admin screen on the left where I'll be dealing with the policy bundle. On the right is the demo application that's calling the Opus server. And again, it's directly interpreting the I D Q L. There is no translation happening in this example. So let's take a look at that.
First I'll show you the demo application. It's super simple. All it does is have a set of links, navigation links on the left. If you look in the upper right, I'm logged in as part of the sales group. And so naturally I can see the dashboard, I can see the sales link. Also accounting, maybe that's not correct, might be a SOD violation. So we'll fix that. Hr, I don't see that link. So let's now go, this is the HEXA policy ui. Again part of the open source system. You can see I can connect to different kinds of environments. I'll select open policy agent and we have some different places where you can store the policy bundle. I have it locally on my machine, could be in GitHub, S3 and so on.
So I'm gonna choose the file, which is this one, say install the provider and we can see it, it connects right away if we click on applications and on this line we get more details and first we format it nice for you. So the four lines do correspond with those different navigation links. You can see here that sure enough sales is having access to the accounting tab down below is now the ID QL in JSON format. And we can do some simple edits here and scroll down to the accounting resource. And in this case we just delete the sales, the sales group save it and we have our opus server polling to reload policies. Why is someone calling me now?
All right, so it, it's polling every, you know, 10 seconds or so and you can see in the bottom here it just loaded, its its bundle server. So we go back to the application, yes we can still see the dashboard and we have access to sales but now we no longer have access to the accounting tab. Great, that's the OPA model. Let's switch over to Cedar and tell you what's going on there. So as you may know, Amazon introduced Amazon verified permissions, a fine green authorization service and a cedar policy language back in December. And when we saw this, we took a look at it and it looked like we could pretty easily map ID QL to this new format. So we said about doing that and we're quite pleasantly surprised at how quickly we could do it. We hosted a webinar pretty early in January to show this.
And so what we do is we don't have that support in our admin UI just yet. What I do have is a command line program that I'll be showing you and we're doing some copying and pasting into the Cedar playground, which is like open FGA and opa, you know have playgrounds where you can simulate policies. So you'll see me do that. I'll take an ID QL policy and JS O format, show that to you, we'll convert it to Cedar, copy that into the playground, test it, we'll make a change and then bring it back and we'll convert it again back into I D Q L with the, with the changes. And that looks something like this.
So again, it's a a command line program at the moment. So in the playground they have two different use cases. One is a photo sharing, the other is a healthcare scenario. So we've slightly changed the the photo sharing situation. So this is an I D Q L policy. It just says that members of the photo judged group can view photos in Alice's album. That sounds easy enough. So Al do this command here, HEXA mapper is the cli of course the target is AWS cedar and the input is this example file that it has showed you. So hit enter and now it's converted it into Cedar format. So I'll take and copy this
And we'll go here to the Cedar playground. So this is publicly available and you know Amazon verified permissions is not GA yet, but they've made some other preview capabilities available. So my policy field over here is blank. So I will paste it and the first thing it does is validate the syntax. So if I were to delete for example the semicolon, you would get a warning message about that down below. Similar to the open model, you have to tell Amazon verified permissions information about users and actions and and resource data and so on. So that's all down here. So I have users, Alice, Bob and and others. And over on the right is a form you can fill out to test your policies. So this one says, can Alice view vacation jpeg? And we hit evaluate and she cannot. Will that make sense? She's not a judge, she shouldn't be able to see that. But Bob is a judge. And for brevity I won't go through the NT entity data.
We hit evaluate and he has access. Well Giuseppe is on the AV team and maybe we want to have his expertise. So can he view this file? No he cannot. So let's change the policy. We'll add an entry to allow the AV team similar access. So I just copy and paste changed the AV team, which he is a member of. Hit evaluate again. Great, now he has access. Does that mean I have one minute Graham? Yeah. Okay, I'll wrap up shortly. So let's go back here. And I have the changed data in this file here. So it's has the A, the vacation judges as well, the AV team. Now if I give you this command, this will convert that back into I D Q L. So we've made the round trip in this example. What's interesting is that I don't know how to write cedar other than copying and pasting and changing one thing.
I don't know how to write rego, but I can manage idq l I can manage a tool like the HEXA UI and gives me a leverage now for managing different policy formats. So we think this can introduce the possibility of interoperability as well as some additional benefits. And I would just in close with inviting you to join us in, in this journey, there are many different ways you can participate from just being an observer or supporter, but you can also get hands on keyboard to contribute code review, code review the review, the spec give us use cases. So we were happy to have you join us and I thank you very much for your attention today.
That was fascinating. Now, just to get this straight, you basically have broken OPPA by encoding the policy in the J S O N, correct? No,
I think it's leveraging its capabilities.
Okay, sounds good. We do have a question here. You demonstrated AWS cda, how complex was it to integrate and how complex is it to integrate other systems?
Well that is, that is quite the spectrum. All credit is to, to Phil Hunt who is on the team and a veteran for in identity standards for many years. Some of you probably know him, so he undertook the, the task of doing the mapping and it, it worked remarkably fast. Probably the fastest integration that we have done in some cases. It's a lot of trial and error to get things right. For example, one thing I did not show you on the repo is we have our backlog there so you can see what we are working on and we use an agile model to do that. And right now we are working on orchestrating between Amazon and Cognito with Azure and Azure ad. And so in, in that case there's a lot of, you know, trial reading documentation and seeing what's possible.
You have fun?
We
Do. Okay. Put your hands together for Jerry, please. Yeah. Thank you. Thanks so much.
