Policy’s role in authorization, XACML today, & OpenID’s new policy charter

Hear about the value of XACML after 20 years, OpenID's new policy charter, how policy relates to authorization...and more!

Kelly O'Dwyer-Manuel & David Brossard
Thursday, September 7th, 2023

Download mp3   ·   File size: 26 MB   ·   Duration: 18:12

Episode transcript

Kelly: Hey, everyone and welcome back to episode two. I am Kelly O’Dwyer-Manuel, the Vice President of Brand and Communications for Axiomatics. And with me as always is our talented and thoughtful CTO, David Brossard.

Hey, David! How’s it going?

David: Doing good! Thanks for asking! How about you?

Kelly: I am hanging in there. So, today there’s always any number of things we could talk about. But today I wanted to to focus on something that I saw last week, which is that we are gosh, over twenty years since the advent of XACML (eXtensible Access Control Markup Language).

So, a heck of a lot has changed in in that amount of time. And the way we look at all things, authorization, particularly from a language perspective, is certainly very much different beast. So I wanted to just pick your brain, David.

What does that journey with XACML look like? I know there’s good, there’s bad, there’s all sorts of things that come to mind for folks when they talk about XACML.

So, what is that journey for you? What do you take away from that?

David: So, it’s the good, the bad, and the ugly, right? I think we need a bit of background music now.

Yeah, like you said, it’s been over twenty years. Oasis was where XACML was born. Both both SAML and XACML, born at the same time. And in 2001, and it was the heyday of SOA service-oriented architecture. It was the the heyday of SOAP-based web services and and back then people were. like, “Oh!’

Well, now that everything is distributed, now that we have a standard way of integrating with these web services, they they weren’t called APIs yet, right? And REST was not even a thing.

Well, now we need, we need to rebuild everything we need to rebuild reliable messaging, eventing authentication better. What we need to build Federation. That was not a thing at the time, right? That’s where SAML came in. And of course we need to build access control. And that’s why we came up with XACML, the eXtensible Access Control Markup Language, at the time.

David: And you know it only took a couple of years for the the first version to come out, and I think the third version, XACML 3, which is the the mainstream version. I think it was ratified in 2010, or maybe a little later than that. I can’t quite remember.

Our founder is is the editor of that version of that language and it’s been great, like the the model, Kelly, hasn’t changed at all, you know. There are a lot of new initiatives and new languages out there, and that’s that’s really exciting, and we’ll talk about that later.

But what’s good to know is that the architecture behind XACML will hasn’t changed one bit.

And, in fact, if you look at what NIST has done with abac with attribute based access control in the formal definition of ABAC (Attribute-based Access Control).

David: They took that architecture verbatim and put it in their in their standard. That’s that’s really inspiring and and good to know that.

David: Zach, we’ll cut that right.

Kelly: For sure. So, I know there are people out there who think of it as kind of long in the tooth. Is that a fair assessment, David? Or is it really just anything that would have been, technologically speaking, around for that length of time would probably be hit with that similar stigma?

David: It’s a bit of both.

I think, overall and unbiased. Of course. I think it’s unfair. I think a lot of the disregard or disdain, I wouldn’t say hatred. Hatred is really too harsh a word. But a lot of the disdain for XACML will comes from the fact that it’s XML-based, and that there’s this misunderstanding that you’re expected to write.

XACML will by hand. No one would ever write XACML by hand. I don’t think anyone about that. Axiomatics knows how to do that, and and where the experts in XACML will, right.

The truth is, you need tooling that abstracts away from the underlying syntax. And that’s what people like people who the detractors of XACML. They didn’t want to see that. They said, “Oh, my God, you gotta write XML, and XML is so wordy.!” I mean, there’s things like JSON and YAML these days do that instead.

So, that’s I think that was the main criticism, but like I said, XACML will define three things that define a policy language. It defined an architecture. It defined a request, a response, a scheme.

The architecture, like, I said, is is very good, very mature. It is still very much being used, not only by NIST, but also by newer frameworks, like open policy agents. Like AWS, etc, and we’ll talk a little bit more about that later.

And then the request, response, and scheme? It’s pretty good. It, of course, only focuses on one type of used case, which is what I like to call binary or transactional authorization.

Can I do this? Yes, you can. No, you can’t. It doesn’t really focus on other things like open ended authorization like ‘what can I do?’. That’s that’s things that we can actually fix in future standards.

And I know that, Kelly, you you mentioned that you wanted to discuss the policy charter at OpenID Foundation, and we can get to that when the time comes.

Kelly: Well, that time is now. In fact, I was just going to say, you know what it’s great to be able to talk about the evolution and the history and and all of that, because certainly as much as there’s now a lot of attention paid to authorization, both from a languages, standards, and processes and frameworks standpoint.

And, boy, that was a mouthful! It’s been around for a while, so it’s important to to look at the the evolution there. But I know there’s some exciting things that are coming up, David, and you’ve been very, very much involved in a lot of that.

So, do you want to share a little bit about what you’re doing with the OpenID Foundation Policy Charter and and some of that stuff.

David: For sure! And and one thing I forgot to mention is that the use cases XACML will wanted to solve twenty years ago, or still, the exact same use cases.

And one thing that I really like about policy and and policy-driven authorization is the whole idea that you take a plain, old English requirement, something along the lines of insurance claims. Processors can only approve a claim in the region they belong to and under or up to an amount that they’re allowed for.

So, these plain old English requirements. They map directly into the technical policy artifact.

Now, whether that technical artifact is XACML or Rico from open policy agent or cedar from AWS.

Another language that I’m not thinking of now. It doesn’t really matter.

What matters is that there’s a close relationship with close mapping between the plain old English and the technical implementation as opposed to what you would have had, what you would have with a role-based or intolerance-based approach where you’re gonna have to go through role engineering.

And and that creates a lot of friction, a lot of loss of meaning, and a lot of need for governance and provisioning processes to assign entitlements and roles to individuals and remove them from those individuals.

So with that being said, if we look at what’s happening, so back in 2015, Open Policy Agent started with their language, great initiative focuses more on the infrastructure side of things.

And then, more recently, about a year ago at Identiverse 2022, a bunch of folks got together to discuss the future of authorization. We met again in Vegas by Identiverse 2023, and we got together to create something called the Policy Charter.

Under the umbrella of the OpenID Foundation and the whole goal of policy, the charter is essentially to get everyone to agree. Not only authorization vendors like Axiomatics, but also non-authorization vendors get us to agree to what a request response schema would look like so that we can achieve greater interoperability.

We’re not really touching the policy. I think we’re at a point where, if you wanna write XACML or ALFA, the abbreviated language for authorization, or Vigo or Cedar. Go ahead and pick your poison. That’s okay! They’re all good a back languages and we’ll be able to manage those and and correlate those.

What matters more is the request response. How you ask a question, how you get an answer back.

And definitely, we can leverage the work done within these actual technical committee within the open policy agent framework within other initiatives, because they’re very similar, right?

So, it’s a matter of streamlining that work.

And then it’s also a matter of going out to software vendors and SaSS developers and telling them, hey, guys, instead of implementing your own homegrown authorization? How about you expose an interface much like you did for authentication?

And and SAML and OpenID Connect, do the same for authorization, and then we’ll come in, plug right into your interface and let you do authorization in a much easier way.

So that was a very, very long mouthful, Kelly.

Kelly: But it’s good and it feels like, David, that this is, and I know you’ll you’ll hold me to account for saying this, but it feels like this is a pretty big – I’m gonna say it – watershed moment for authorization that we’re looking at things for this market in this way, that we’re no longer looking at it from which language is better OPA, or XACML, or AlFA, or whatever it is.

We’re looking at it from that kind of holistic broader, “what is the problem we’re trying to solve?” point of view. And that’s huge.

David: It is absolutely so. There’s this realization that different individuals, different profiles, if you will like to write with different languages.

I think we can all agree that the XML syntax exact will is is to verbose to be written by hand.

But we do know that developers still wanna write languages by hand. So they wanna write Rigo by hand, so it has to be a syntax that is easy to write. So Rigo was one attempt, or is a very good attempt.

ALFA, the abbreviated language for authorization, same thing. A very good attempt at making a language easy to remember, easy to write, easy to read, easy to understand cedar, similar things, right?

So it’s all about saying, “Okay, pick the language that you prefer and start writing in that language”.

And you know what if you have a team of infrastructure-minded developers who want to do Rigo and a team of business minded developers who want to do ALFA and a team of I don’t know AWS folks who wanna do Cedar, then let them do in their own language as long as there’s a layer to sort of orchestrate or correlate the policies from a mainly from a governance perspective, not from a runtime perspective. Then that’s okay.

And as a matter of fact, there’s another initiative called IDQL that is, spearheaded by real good friend of mine, Gerry Gebel, a former Axiomatics employee, And IDQL aims to be the orchestration language on top of these runtime languages.

That’s that’s also an interesting space to keep an eye on, to see what’s gonna happen with orchestration.

Kelly: That makes total sense. And, yes, I think IDQL is all of a sudden, in a very short period of time, commanded quite a bit of attention. So that’s a that’s a great thing. It’s exciting to see that there’s an appetite out there right to to learn more and to know more, and to see how we can go bigger, faster, stronger with all of this.

And I think to that point, David, and that brings me to the next area of conversation and and something that we’ve chatted about, certainly on numerous occasions is around, okay, now we say, we’re talking about the the challenges that authorization solutions are looking to solve.

There is still, it feels like a lot of obscurity, perhaps around or under lack of understanding, I guess, is what it really is, around, what it is authorization can solve, and at its core a lot of what what our market can do is solve challenges that that organizations have around policy?

But I really don’t think that’s very well understood.

I know that we’ve talked before about some folks just don’t associate authorization at all with policy challenges.

And you have other organizations, then, that bring in an external authorization solution and think it’s going to be their easy button if you will around all of their policy challenges.

And it’s really not that either, so that’s a very long winded way of of of asking you, David, I know you have an opinion about the entire policy, lifecycle, management, conversation, and the role that authorization should play.

Do you want to talk a little bit about how you see this kind of helping a better foster a better understanding of policy and addressing those challenges?

David: Yeah, really, really good question, Kelly!

And and I think there’s there’s at least two angles that I want to tackle, or two reasons why customers go down the path of policy-driven authorization, and one of them is developer efficiency as a developer.

I don’t wanna have the rewrite code to tackle my authorization scenarios time and time again, I just wanna externalize it much like as a developer.

I don’t wanna have to build in my authentication. I build from scratch my authentication. It would rather have a utility, a library where something is service that would handle that for me, right?

This is the same reasoning.

But there’s another dimension which which you touched on which is that oftentimes you have policies that come from potentially outside the organization or outside that that developers team around what can or can’t happen.

So, if you take my entrance policy example or my entrance claim example again. It might be that you, the developer, you’re writing an API to expose data to the customer right?

And so the customer they have a website they can go to. They have a mobile app that can go to and they can browse their insurance policies, they can browse it or create claims, they can view the status of their claims, and so on, so forth.

Employees can do stuff as well, like browser claim, approve a claim, deny a claim? So on, so forth.

And the the naive way of doing this would be okay. I, the developer. I’m gonna develop an API, and yes, I’ll be handling authentication through you know, OAuth, or Open ID Connect, or whatever.

And then, I’m gonna be handling authorization in my code. So I’m gonna write things in my code and and Java, or whatever language I’m using, I’m gonna see things like, if customer ID is equal to owner of the claim, or if the amount is less than the approval limit for the claims processor, then what happens is the business side of the house.

The business side of the entrance company might say, “Well, these are my requirements, and those might change over time and they might change because the business changes, or it might change because of external factors, legislation, compliance, audit needs”, so on, so forth.

And so now the developer would have to rewrite those those elements in their API right? So they would have to launch or release a new version of the API.

Now take that, and instead of hard coding it, extract it, externalize it into a policy driven approach. And what happens now is you write a version of your policy.

You do have a life cycle that needs to happen around the policy because, the developer might be the one writing it.

But of course, it needs to be approved by perhaps the product manager. It has to be the the business analyst need to be consulted. You could almost think of a racy diagram around the policy life cycle management.

And then eventually, you know, you get a version, one dot O of the policy.

What’s cool is that the policy is just configuration.

Creating a new version of the policy to tackle new requirements or to tackle of changes in the requirements.

That’s a matter of minutes, if not seconds, as opposed to rewriting code and having to go through the life cycle of of code management. Quick change. It’s it’s much easier to do that with policy.

And that’s the one of the most compelling aspects of doing policy.

And it’s probably one that people don’t necessarily realize as much when the requirement are when our customers come to us, and they say, “Oh, we need a proof compliance with X,Y, and Z”. They typically only think about the compliance needs not the efficiency of the developer.

And then, when when it when we come from the developer. They only think about the the efficiency gains not necessarily the ability to prove compliance with X,Y. And Z.

But, in fact, it’s both. It’s the best of both worlds.

Kelly: that makes a ton of sense, and I may be jumping ahead to to future episodes. But it’s really, almost speaking to the the case for DevSecOps, and how to really empower a DevSecOps model through rethinking policy.

But now I think that’s an incredibly worthy conversation, and what I very much wanna have with with you.

But I realize that we are almost at at time here.

So, David, thank you, as always! We got through a heck of a lot of stuff, a lot of topics today! Insightful as always thank you very much for the time.

And thank you to everyone who’s listened! Please come on over to our LinkedIn page, visit us on YouTube. Come on over to the website, and we’d love to to chat further on on this or any other authorization related topic!

David: Yep! Feel free to reach out to any one of us! We’re always happy to hear from you!

Podcast RSS   ·   YouTube

Media Contact

Samantha Berno
Corporate Communications Manager
Axiomatics
samantha.berno@axiomatics.com