Martin
Welcome. I'm here with Dave Brossard and with Allan Foster, and we are here to talk about, let's say, the future of authorization and how this impacts digital identity and the digital business. And the term they will use is AuthZEN. So be curious. Stay tuned. Welcome, Dave. Welcome, Allan. Can you quickly give a bit of a background, of the two of you, and then we dive into AuthZEN.
Dave
Sure. So my name is, David. I'm, CTO at Axiomatics and one of the editors of the XACML authorization standards that goes back all the way to 2001. Al and I were partners in crime at XACML and we had so much fun we want to do it again with AuthZEN.
Allan
Yeah. So I was involved with XACML back in the Sun days. And then with Forgerock, definitely XACML, so I've always been authorization based from day one. And the challenge we were looking at, David and I started talking, I don’t know, a couple of years back, and we start looking around and saying, one of the challenges that enterprise is having is managing all of the different systems, because every system has its own authorization framework and an authorization policy and everything. And that's really where I was in, as the working group came up.
Martin
Okay. And maybe to start XACML stands for Extensible Access Control Markup Language. It's a, as the “ML” indicates, and the X, it's an XML based standard. Started quite a while ago, two decades, more than two decades, had some quite big peak in attention. And then it became a bit quiet, I think, which is partially, because of the complexity of authorization and partially because XML turned out to be more on the heavyweight side of things, let’s phrase it like that. So what is different?
Dave
So a few things. First of all, you're right. Like, you know, XACML was XML based and, XML eventually fell out of favor. We came up with Alpha, the abbreviated language, for authorization to help with that. But it didn't solve the fact that authorization is a really hard problem to solve. Because you're kind of sitting here. There's the identity side of things. There's the application side of things, and authorization kind of sits in the middle. It's a very uncomfortable position. I think what's changing is, people who have been working on authentication, they're done with that. It's more or less mature, right. Authentication is fixed. So companies have time to focus on authorization. One thing. The other aspect is there's more data, more users, more services, more apps, more risk. So you need to do authorization. And that's where AuthZEN really comes in. Because XACML was great. The model behind it was great. NIST took it, created ABAC. NIST ABAC in 2013, I think? And now we're, you know, within OpenID, we're saying, well, let's build the standard interfaces for authorization. That's what we kickstarted last year.
Allan
Yeah. I mean, XACML. So the number of times we stood around and people are saying, XACML? XACML is dead! But the reality about XACML, it is introduced. And still to this day, when you're talking about authorization, the concept of a subject, a resource, an action, a context. That was really one of the big things XACML brought into play step by step. Okay, maybe now we should be using JSON instead of XML. But ultimately, the question and the one thing I want to add on to what David said, it's that the additional thing that's made it a lot more complex is outsourcing of a lot of apps into SaaS apps and cloud apps, which means that the enterprise no longer has control over how it works, and it's buying into the service. And so that makes it, again, inherently more complex.
Martin
And you still need to manage authorizations, that I think doesn't go away. And what I am currently observing, it’s interesting to see when I went to talk is a lot of people, as analysts tend to do, there are a lot more talks right now about authorization, about policy based access control, whichever term you want to use. And one of the, I think the fears which are starting to grow is that we see a lot of sort of grassroots authorization approaches. So, getting authorization, a lot of applications in the development of applications like we have with OPA, we see things happening, and the big cloud platforms with different types of initiatives and so the fear is a bit of ending up with, let's say, policy islands at the end of the day where you have relatively isolated solutions, and then you need to bring these things together. So is this something where AuthZEN will help to get a better grip on that?
Dave
It will a little bit, but there's other initiatives too that will help. So first of all, the fact that you land with policy islands, it sounds scary, but is actually good news because it means we're all thinking in terms of policy. So it's a first good step. It also means that the architecture is fundamentally the same. You know, the PDP. So that's a great start, right? It might mean that we need to have policy translation in place or policy governance. So if you look at Gerry Gebel and Strata Identity and the Hexa Open Source framework, they came up with a language called IDQL, that is not meant to be a runtime language. It's meant to be a governance language. And they're translating back into Rego for open policy agent, Alpha for authorization, eventually, maybe one day Cedar. So it's yes, you're right. There's there might be islands. But the good news is, same architecture, the ability to manage these policies in a single language. That being said, is not what AuthZEN is doing at the moment.
Martin
So what is it doing?
Dave
We decided, right from the get go that we did not want to do policy, because you're going to get into very heated conversations about what the policy should look like. And, you know, there's the Rego camp, the Alpha camp, the Cedar camp. We don't want to do that, right? We want to focus on request response, first and foremost. How you send a request, how you get a response back. We've got three PIs in mind. We've already got the first one figured out. The first one figured out is the binary one. Hey, can Alice do X? You get a yes or no back.
Martin
Or something in between?
Dave
Not yet. So. Well. So, we... Allan can talk about obligations and advice. The second one is a batch version, or the box carrying version of the first one. The third one is the search one where you can say, hey, what can Alice do? Which means that you can get a list of things back instead of just a yes or no. But also to your point, Martin, we are thinking of returning additional context, and that's something that's close to your heart, isn't it?
Allan
It is. And there's multiple layers, right? It's not a we don't want to do policy. But that's a really big problem. And we'll get there. One of the things that we looked at was looking at the basic request response of any authorization thing that needs to be done. That's what you have to do. You've got to make a decision. If we can make that, and most of us do it sort of the same way, and if we can make that standardized, it means that the developer doesn't have to make a decision about the decision point while they’re working on their app. They can change it on the fly, and use where they are going. Returning context, I think it's very important because at the point of enforcement, there is a lot of context that we can make decisions about. You know, the famous one is step up authentication. We want to be able to send that back, to say, by the way, if you do the step up we could give you a different policy.
Martin
Okay. So basically you're doing it bottom up, while IDQL is more top down. Honestly, I'm not very scared about policies because you already said it. Policies always have the same structure. Action, object, constraint or context, however you phrase it, but real world policies look the same, like authorization policies, like authentication policies, like firewall policies, etc.. So I think that is the good thing. The language we express it, varies, but the structure is the same, which means translation is relatively simple to do. Especially we can always start with natural language, which I believe is a huge advantage if we want to define policies, that we can talk with people that are not geeks about that in a very natural language. Every departmental manager in an organization, for instance, the finance department can very well describe the policies. And that also means you have something where you can derive your roles and your entitlements and all that stuff from. So I think it's not as tricky, but I get your point. There's the other side of it. So, what is it what the developers use in a standardized manner so that you build an application and that application can work with every system. And if you move from cloud A to cloud B, from system whatever Z to system whatever else. For the authorization then the code won't change, because it abstracts all these different models. And that at the end of the day, also, I would say, both things then help us to get a grip on the policy islands. The one is, you build your application so that it's not tied to a specific approach. And the other is, you consolidate your policies, especially your policy governance and management, and then maybe at some point of time, we have more automated translation of high level policies into lower level policies. And then you can, as an organization, build this, this roof on top, so to speak, or to the house around all these things, to get a grip on it. While you, and I think this is very important these days, while you enable a multi-speed evolution in the entire policy and authorization space. So developers love it because they don't need to care about it if they just have a call out of their applications. But to fix it in legacy applications with standing privileges, it's a longer way. So we will have multi speed, but hopefully then at some time one framework on top. So it's, so what you're saying basically is, you build a three API standard.
Dave
A three PI standard. That's the first goal. Second goal is design patterns. Because we also acknowledge the fact that there's the, what I would call the traditional authorization PEP, PDP, PIP, so on. But there's also the also the OAuth way, the token way, the session way of doing authorization. We kind of want to bridge the two worlds. We cannot ignore the OAuth way of doing authorization.
Martin
But I think in OAuth we also have this, I think also evolution starting around getting away from static scopes. Which I think is very important. I remember, having started, I think Allan you also were part of that, having started some conversation about this, a couple of years ago already. Where I said, I really would love to see dynamic scopes in OAuth, which then are derived. And that would be the question, what can someone do, which [...] are derived from the setup of the application, because this has the huge advantage that not the developer or someone who's not really responsible for the part of access control, defines scopes, but that you leave it to the people who are really at the end of the relevant for that.
Allan
Yeah, I mean, dynamic scopes and the entire issue of that within OAuth solves a lot of access control, but it doesn't solve them all. But it's also a lot of the problems. And where you have a technology that works that’s simple and straightforward, that solves 70% of problems, you look for that 70%. You know, it makes perfect sense that most cases are happy with static scope. In the case this doesn't work, then we've got, you know, dynamic scopes. And I think that in.
Martin
Maybe it's that in most cases we learn to be happy with static scope, but would be even happier if we would have dynamic scopes, that might also be the case. So but I think this gives me and hopefully everyone listening to this, an idea of what AuthZEN is, where it's heading. So one question more to you. Do you need further supporters? If so...
Dave
Yes, absolutely. To go back to your to your previous point where you were saying, you know, it's two approaches, right, from bottom up, from the developer point of view and top down from the policy governance point of view. So going at the bottom, we're asking, you know, all of these SaaS builders, the COTS builders, look at AuthZEN and start thinking about externalized authorization, start building the hooks so that you can take a Workday, a Salesforce plug in into an AuthZEN product, and then the call to action to end consumers, end customers, much like you required your products to do OAuth and SAML, request the same thing with AuthZEN, right? You should not have to re-implement your authorization configuration in different ways in different SaaS frameworks. It should be of AuthZEN.
Martin
Okay. Dave and Allan, thank you very much for all the information provided. It helped me understanding what you're doing currently. Thank you for everyone listening in to this talk. Pleasure having you here.
Dave
Thank you. Thanks, Martin.
Allan
Thanks a lot.
