Authorization with David Brossard

Vittorio Bertocci: Buongiorno everybody and welcome, this is Identity Unlocked. And I'm your host, Vittorio Bertocci. Identity, Unlocked is the podcast that discusses identity specs and trends from a developer perspective. Identity, Unlocked is powered by Auth0. In this episode, we focus on a topic that is somehow always in fashion, but it seems no one figured out it just yet, authorization. Today, we are chatting with David Brossard, Senior Director of Identity Product Management at Salesforce, and the closest thing to an authorization veteran you can find. Welcome, David.

David Brosard: Thank you. Hi everyone. Good to be here.

Vittorio Bertocci: Thanks for joining me today. It's a longstanding tradition of Identity, Unlocked at the start every episode with a story of how our guests ended up working in identity. David, what's your story? How did you end up working in identity and in particular, authorization?

David Brosard: So I actually didn't start in identity, not even in security. I did not even know what IT security was to begin with. I did a student placement in the UK back in 2003, and that was at British Telecom in one of their labs. And I was focusing on natural language processing, which is what I liked the most at the time. And then when I came back the following summer that lab didn't exist anymore, but they had positions in security, in SOA security. SOA was the fashionable term back in the day, right? Services Oriented Architecture. After the placement went back to university and then went back for permanent position at BT and worked on SOA security for five years, doing R&D, working with protocols like SAML, XACML, BPEL, WS-Trust, WS-Federation, one of your favorite ones, so on and so forth. So the whole nine yards of WS-Star.

Vittorio Bertocci: You know that my license plate is still WS Star. Right? My car says WS Star, still today. Well, not that nice, but it's a reminder of "no protocol lasts forever".

David Brosard: I'm sure you've heard of the WS Death Star, right?

Vittorio Bertocci: Yeah, absolutely. Yes.

David Brosard: So after that, I hopped on to a startup that focused on authorization only. And that was Axiomatics. I was there for 10 years. One of the early people in the team, I was actually an early customer of Axiomatics before joining Axiomatics, did a lot of fun stuff. Worked a lot with customers, worked a lot with OASIS, the standards organization, worked with NIST, had a lot of fun. And then 10 years on. I was like, " Well, maybe I should see what other standards and technologies there are in the identity realm." And that got me to Salesforce where I focus more on identity standards. Things like OpenID Connect, Off and even SAML as a matter of fact, that's me.

Vittorio Bertocci: Fantastic. It's such a great trajectory. And the only the geekiest of geeks would say that"This was fun" but of course that feeds the character. So, great. Thank you so much for sharing that. So you clearly are one of the best people for talking about authorization and standards, especially from what you just said, so far. But before we dig into the standards, let's just talk about authorization, in general. So what is it and what makes it so hard to capture it in standard form?

David Brosard: There's a few different reasons why people struggle to understand what it is. First of all, there's a bit of a misnomer. Oftentimes people will think that when you authenticate, you authorize. So there's this conflation of two ideas that authentication equates authorization and vice versa, which of course isn't the case. Authentication is about proving something about yourself. I like to say it's proving something about yourself more than proving who you are, because you might just want to prove that you're 21 years of age. It doesn't really matter who you are. What matters is that you're 21, that's authentication. Authenticating a claim essentially about yourself, usually your identity, right? But even then, take an extreme case when you go through borders. They're not really looking at the fact that you're Vittorio, they're just making sure that you're not on a blacklist of sorts because you did something bad in a past life that we're not going to disclose on this podcast. And you're not allowed to go through customs anymore. Hypothetical example. So authorization, however, focuses on once we know what it is you represent. Once we know who you are, authorization will let you determine what you can or can't do. It's both things you're allowed to do positive cases, but also things you're not allowed to do. And you were asking why it's so hard to crack that nut. Why is it so much easier, relatively easier to do SAML and all the identity protocols instead of authorization? I think it's partly because identity and authentication resides entirely in the hands of the identity teams. It's easy to concentrate into one side of an equation. Whereas authorization is a mixture of who you are, so identity information, but also what it is you're trying to get access to. So now you're entering the realm of the application and the application data model and all the data that resides behind that. And it's also potentially contextual information. You know what time of day it is, where you are so and so forth. So because authorization is built on these three different things, it makes it harder to solve because you're going to have to involve multiple teams within the same company and coordinate those teams to be able to define the authorization and achieve what it is you want to do.

Vittorio Bertocci: That's interesting. So you're saying that authentication is something that is prone to be centralized, but authorization is always an emerging phenomenon and your list is the sum of all the things that determine what the authorization will do? That's such an interesting and concise way of putting it. Fantastic. Great. So let's dig even deeper. Are very common types of authorization, that one is more likely to encounter, that would require them to be handled differently?

David Brosard: Oh yeah, definitely. And authorization is definitely a soup of a lot of acronyms and different authorization types, but if you want it to simplify it, there's essentially three main types. The very first type of authorization that predates us both, going back to the'50s, the'60s, and the'70s when we're developing operating systems, is of course access control lists. Being able to define an item, an object, typically a file, and then on that file, you say," Hey, Joe can access that file." The second type that emerged around the'90s, 1992, I think, is when we see the first traces of that model, is RBAC, or role- based access control. So R- B- A- C, and RBAC was born out of necessity. The realization back in the'90s was that ACL's were great. They were extremely fine- grained because you could literally say here's an item, here's a person, boom, they can do rewrite or delete, the typical actions you can do. But it was really hard to manage. So role- based access control is here to provide a framework, to make the management of authorization simpler, to define the notion of a role that you can assign people to, the notion of a group that you can assign people to. And also with roles and groups, defined hierarchies between those roles, so that you can have inheritance between the roles so that you can say," Oh, if role A can do this and role B inherits from role A, then role B can do everything that role A can do." That made the management of authorization simpler, but both in the case of ACL's and in the case of RBAC, you're very much identity centric. All you're looking at is the user and what they represent, who they are, and you assign them to a role, you assign them to a group. So that's very, one- sided. A new model that emerged, actually that emerged as long time ago as well, but that really matured around the 2010s is ABAC, or attribute- based access control. So both RBAC and ABAC are models defined by NIST. And I keep forgetting what the acronym stands for. I think it's the National Institute of Standards and Technology, if I'm not mistaken, or where Science and Technology.

Vittorio Bertocci: We'll find out, we'll ask the Google before publishing the episode.

David Brosard: Exactly. So I don't look like an idiot. So NIST started formalizing RBAC in the'90s, and formalized it in early 2000 and then did the same with ABAC in 2013 or 2010, 2013, I think.

Vittorio Bertocci: I thought that MIT or Stanford had some role in that, as well.

David Brosard: Yeah, so it's a very good point. So this is interesting what you're saying Vittorio, because it's hard to go back to the one original source of the model. So ABAC was formalized by NIST in 2013, but the model was not their invention. There was something called FGAC fine- grained access control, which is a form of ABAC that was developed for databases back in the early 2000s. So you can always go back to a previous model that looks very much like ABAC. And ABAC isn't rocket science at the end of the day, it's just realizing that you have identity data on the one hand, you have application data or application processes on the other. And you want to be able to control access to the processes and the data by using attributes or metadata about the user, and about the objects, and about the resources, and about the applications. So the formalization of the term, ABAC is 2013. Is there a bottle before that? Oh, definitely. I'm sure there's more than one.

Vittorio Bertocci: Yeah. I remember like when we were playing with WS-star and CardSpace, that making decisions based on the claims inside the tokens we were sending, with those claims not being only roles. Like of course you could use those to carry roles, but you could also carry any attribute. And so if you could make decisions based on those attributes that turned it into authorization decisions, then you could do it. But yes, we didn't call it ABAC back in the day.

David Brosard: Yep. And neither did we, one of the projects I did R &D on was a project called Trustcom. And this is where we used a mixture of XACML, SAML, we had an STS, it was actually built by Microsoft back in the day. So a Security Token Service, and what that STS would do is, you would give it a username and password. It would return SAML token on the issuing side, on the validating side, it would receive a SAML token and say," Yes, the user is who they say they are." And like you said, inside of that SAML token, you could have claims or assertions that described the user. And then what you would do is you would send those claims to a policy decision point and get a decision from that policy decision point. And I'm already mentioning terms like PDP. So ABAC formalizes those terms in the NIST spec. But of course they're not invented by the spec. They're really old, PDP existed in the XACML spec, which is older than ABAC. And of course, PDP was mentioned, I think, in network access control, specs way back in the'70s and'80s, that definitely predates ABAC and XACML.

Vittorio Bertocci: Now we are starting to get into actual names salad. So let's take a step back. So before going farther, I heard you listing three different types of authorization. You mentioned ACLs, you mentioned RBAC and you mentioned ABAC.

David Brosard: Correct.

Vittorio Bertocci: Great. Perfect. And I remember a panel at one of the last in-person Gartner. Yeah, before the disaster hit. And I remember the panel was someone from Microsoft, someone from AWS, and someone from Google, and one of them was saying that for all their roles, RBAC, basically they were saying something like a crazy number, like, 90% of the roles defined, were actually never used at runtime. And that's why they were suggesting to go toward ABAC. Before we move it to actual specs, do you want to comment on that?

David Brosard: For sure. So there's a couple of different things. I guess you could rephrase your comment with the following question. Why do ABAC, why not just stick to RBAC if RBAC works well? Well, with RBAC, you get a lot of management pain, with RBAC, you get role explosion, as well. To be able to cater to all the new scenarios you have to invent new roles. And those roles eventually either get used and forgotten and then dropped or never get used, like you said. I had some metrics from customers in my previous life where they ended up having 10 times as many roles as they did employees. And that's just, that's an indication that they were trying to solve for an authorization challenge and they were not doing maintenance on the roles because what happens is the following. You have a company say a bank and they develop one app. So the app developers will go to the central IT team responsible for identity, the LDAP team, if you will. And they'll say," Hey, create me role A, role B, role C." And because there's no good governance or there was no good governance on the role creation, the role maintenance, the role provisioning, the role deprovisioning, you end up with more and more roles. And then oftentimes what'll happen is application one needed a role to do this much, a sliver of functionality. And then application B comes along and says," Well, we need this thing plus a little bit more, but not that little bit." So it ends up creating yet another role that is like 95% of the same thing as the previous role, but not quite the same. So that's kind of the mess that RBAC put us in. RBAC is definitely good, you need it, it's not going away. I'm not saying it's going to go away, but there's definitely management issues and granularity issues that you have with RBAC that ABAC is trying to solve.

Vittorio Bertocci: Fantastic. Super insightful. We'll get back to it, as soon as we do our little historical detour. So you name dropped a XACML and SAML and similar; so if we were to go back in time, as far as your memory goes and start from there, what are the main attempts at formalizing authorization in standards?

David Brosard: Yeah, the main main one of course is XACML, X-A-C-M-L, and it dates back to 2001. So it dates back to what I called the SOA craze, the services oriented architecture craze, where you had two camps, you had the W3 camp that were developing a lot of the WS standards. And you had the Oasis camp developing a lot of the SAML and XACML and other standards in that category. And SAML was seen as the new federation protocol. And XACML was like the little brother, seen as the authorization protocol that was being invented. But before XACML, there were other attempts. One was called Secpal, S- E- C- P- A- L, that was developed, I think by a couple of universities in the UK, if I remember correctly. There were industry specific or vendor specific attempts a little later where Microsoft had something called SDDL for instance, that came in windows server 2012, if I'm not mistaken. So there were different attempts more recently in the industry. There have been things like open policy agent and Rego, the language for open policy agent. You have things like OSO and their language, I think called Polar if I'm not mistaken, for authorization. So these are more recent attempts. And then-

Vittorio Bertocci: So before we go all the way to the current, let's go back for a moment with XACML, mostly because you mentioned that it defined some of the artifacts that then we also use, elsewhere. Like the sum of the concepts that we find in there, even if you don't follow XACML as is, but you still use the same language, PDPs and stuff like that. Can you expand on it on what did XACML try to define, what artifacts did it introduce?

David Brosard: Yeah. Very good point. So XACML ended up defining an architecture with the components, so we can get back to them in a minute, it ended up defining a policy language, and it ended up defining a request response protocol. Now the architecture, like you said, and like I mentioned before, although XACML does define it. It actually steals from other ideas, mainly in the network access control space, way back when. And the building blocks you'll find in the architecture are the PDP, the policy decision points, so that's kind of like the engine in the architecture. The PAP, the policy authoring, or the policy administration points, which is where you manage your policies. The PIP, the policy information point, which is an interface through which you can fetch missing data that you need for decision- making. For instance, if you're asking," Hey, could Vittorio drink?" The question you're going to ask the PIP is" What is the date of birth? Vittorio's date of birth." The last component I didn't mention is the PEP, the policy enforcement points. The enforcement point is responsible for enforcing the decision. So it's the integration, the glue, if you will, between the application or the process you're trying to protect and the decision point, the policy decision point.

Vittorio Bertocci: Well, that sounds very comprehensive. All the functions that you described, it seemed to need to have a counterpart in any architecture that needs to do authorization. So they gave us nice terms, although we might actually end up not using exactly their protocols and the exact messages that they described. So basically XACML is one of those things that everyone knows what it is, but as far as I know, very few people actually implement it. So is it true? Is it the line with your experience? And if yes, what went wrong there?

David Brosard: That's a good question. So it's definitely not as popular as I would like it to be, as it would have liked it to be, anyway. Part of the issue is that authorization was just hard to implement. And at least in my tenure, from 2010 to 2020 roughly, people were still struggling a lot with identity challenges. And if you don't have a mature identity architecture, it's going to be hard to move to the authorization phase. You have to have a good clean identity basis in order to be able to implement authorization. But putting that aside, there's a lot of challenges because what you do, if you compare RBAC and ABAC, for instance, RBAC, you can read from your LDAP. Everyone knows how to read LDAP, it's not a sexy protocol, but everyone knows it. So if you're building an app and you're told," Oh, you can either consume roles from the LDAP, or you're going to have to write an enforcement points and write policies that you have to store it in a policy decision point." Well, it seems like the RBAC approach is an easier way to tackle authorization, although it won't do everything you need to do. So a lot of the challenges that XACML was facing, or has been facing is educating developers, showing developers how they can easily decouple the authorization from their apps, stop relying exclusively on roles, show them how, instead of just doing roles that can do policies. And then they can get the benefits they can start leveraging XACML or open policy agent or polar, if you look at the newer languages. I think there is a steeper learning curve with ABAC and XACML, because it requires more things to be put in place than there is with RBAC. There's a couple of other differences, Vittorio, by the way, that I forgot to mention, we said that there's, A-C-L-s, ACLs, there's RBAC, there's ABAC, they're not all directly comparable. Although they're all authorization models, if you will, ACLs and RBAC, they're what I call design time authorization frameworks. Where the authorization has been decided at the creation of the file or at the creation of the user, typically. And then as you evolve throughout the lifetime of the employee, for instance, you're going to add and remove roles from that employee, but that happens every month or every year, they need to depends on what you do. XACML is a runtime authorization model where every single time you're attempting to do something, there and then we're going to check whether you're allowed. That also makes it potentially a little harder to implement, or at least it requires a different mindset. If you're used to working with RBAC, then you're going to have to start thinking differently to be able to leverage ABAC and XACML and OPA and all the other ABAC implementations. Does that make sense?

Vittorio Bertocci: It makes a lot of sense. And I find it fascinating what you said about educating developers about extracting authorization from their code and actually relying on an external engine. And I'd say that today that's a pretty well- established meme. It seems that people expect to be able to do these through gateways or through edge services and through engines and similar. So if we were to leave XACML a bit behind and look at what's a popular today, what would you say are the most popular approaches to offer authorization, that you can think of?

David Brosard: Yeah. So one thing that happened five years or so ago is essentially APIs matured to a point that they became microservices. And applications that once were one big app were broken down into smaller applications becoming those microservices. And Kubernetes became a thing and Docker became a thing. And what that meant is that we had a lot of interfaces where suddenly we had an opportunity to control what was going in and what was going out more easily. And therefore we had an opportunity to do authorization, a much more fine grain authorization. And in came a company called Styra, S- T- Y- R- A, and a standard that they invented called OPA, open policy agent. Actually it could be more specific open policy agent refers to their decision engine and then Rego, R- E- G- O, refers to the language you use to configure the language. And I think, if you wanted to compare XACML and Rego, they're more or less at a very high level comparable in terms of language functionality. What's interesting though, is that Oasis and XACML were created kind of with enterprise in mind. And what I mean by that, backed by large companies like Oracle, Sun and so forth, whereas open policy agent is way more pragmatic. They were like," Oh, we have an issue in Kubernetes. We have an issue with infrastructure. We have an issue with microservices. Let's find a way to address that from within that particular realm from within CNC." And that's kind of what happened, which helps with developer adoption, because it was not created within a vacuum. It was created for the developer by the developer within that space. And that's like today, if you look at microservices and if you look at authorization as a whole, if you Google authorization, you're more likely to find stuff on open policy agent than you would on XACML because they started from the developer challenge. Does that make sense?

Vittorio Bertocci: It makes complete sense. Yes, that's great. And so it seemed like there is like a growing interest in this space, mostly because with the proliferation of things like microservices and similar, the cottage industry, in like a writing code in your methods for dealing with if it becomes unsustainable, very hard to manage. So it's understandable that this thing is being so popular. So now just to go left field for a second, one of the recurrent protagonists of Identity, Unlocked is OAuth and its relatives. OAuth famously has authorization in the name. But we almost did the entire episode without mentioning OAuth. So how would you explain this paradox?

David Brosard: Yeah. So you make me think that I forgot to mention something else, XACML and attribute based access control and role- based access control, and I'll stop there, I'm not going to talk about ACLs. They tend to be enterprise driven, enterprise defined authorization, where someone in the enterprise is going to say," This is what's going to happen. This is how it is." ACLs could be user- defined. So there's another standard that I forgot to mention, along with OAuth and that's UMA user managed access. So that's another authorization standard., I had to bring it up if only for Eve. So these are really interesting standards because they do try to address authorization from the other side of the room, if you will, from the user managed, for the user defined side of the room. So OAuth fits partly in that bucket. It's more about access delegation. It's more about... The typical example I'll give a Vittorio, you know this better than I do is, I've got a Facebook account, I've got a Twitter account, and then I'm going to connect the two together. And Facebook is going to say," Hey, will you David, give me access to your Twitter feed so I can read your feeds. I can write to your feeds. I could update your profile." That's a typical OAuth use case where you're delegating access to one system on another system that you own. That's exactly what OAuth is for, possibly in the consumer world. Another great example would be, if you wanted to connect your finance app, say Mint or whatever, to your different bank accounts, then you would not want to share your password, you would want to do that OAuth flow. So, OAuth I think Ping Identity called it at some point the solution to the password and type pattern, to be able to not have to share a password. So that's what OAuth is about really.

Vittorio Bertocci: Right. And here admit that I baited you, but the thing is that in my experience, so many people get their first exposure, especially non enterprise people, to the idea of authorization when they start using OAuth. The man with a hammer syndrome ensues, and now they start trying to solve every authorization problem with OAuth. Which unfortunately, as we know doesn't work. Because in this scenario we just described, with Facebook and Twitter, you are allowing a third party client, like Facebook, to access your private resource, which is Twitter. But what you can do with Twitter, if you'd be only looking at Twitter, the way in which you are authorized, so that you can tweet from your feed, but not from mine is not done through OAuth, Twitter needs to have found some other solution ACL or all the other stuff that you said. They cannot use OAuth, but OAuth comes into play only when there is a third party client. So, that's what I was trying to bait you into.

David Brosard: Very true. So behind the scenes at Twitter, there must be code somewhere, somehow that understands what the claims mean and let you do the authorization baked into the application. Absolutely. Totally right. Yes. And also Vittorio, what you said is really interesting, developers get exposed first through OAuth. I fully agree with that because at the end of the day, when you want to call APIs, the first thing you have to do in 99% of the cases, is authenticate yourself. If you cannot authenticate yourself, you're not going to go any further, so nevermind authorization. And yes, because now they're exposed to OAuth, they're going to start using the mechanisms that OAuth gives you to do authorization. So essentially claims that you can put inside of your access token so that it can be processed by the resource server. And then what's going to happen is, you're going to end up with the same problem you had with role- based access control, which is we called it role explosion. Now you can call it claims explosion or token bloat, because you're going to end up with a token that has way too many claims with respect to what it is you wanted to do on this server. Absolutely. And lack of visibility.

Vittorio Bertocci: That's so very true. And the thing of it that drives me insane about this stuff is that this is a classic problem that emerges only at some scale. If you're doing your toy model, in which you are just doing your proof of concept, just to convince yourself that something works, you would probably not stumble into this. Because your test tokens are going to be small, but then you're going to production with this thing. And you discovered a user that belongs to 385 groups with transitive closure. And so you end up with these tokens that basically break your routers. So yeah. I'm so glad you brought it up. Great. So I don't want to abuse of your patientce, you've been super nice. So what do you recommend that people keep an eye on today? What are the most interesting things to monitor in the authorization space today?

David Brosard: I think you want to keep an eye on things like OSO and Polar. So that's one company in the language that they use, it's interesting. You want to keep an eye on open policy agent for sure, and Rego and where that goes. Google came out with a model a few years ago called Zanzibar, and there's a couple of companies implementing it. And then a couple of companies, including, I think Auth0 taking a spin on Zanzibar, in Auth0 labs to try and see how it can help with API security. So these are things that you want to look out for. One that's close to my heart is ALFA, which is the abbreviated language for authorization, which is essentially a streamlined simplified JSON-like version of XACML, if you will. So it's way easier to write for the developers than your traditional XML XACML syntax would have been. So these are the things I would look out for. I would also make sure that when you're implementing an application, you want to look at what that application framework gives you because we've talked about standards. And standards are great, I love standards, but if you develop in one application framework that already has some pretty good or pretty okay authorization capabilities that are not standards based that belong to the framework, then that could be good enough for you. A great example of that is Spring Security. So if you're developing in Java, and I know Java is a bit old school these days, but if you were doing a Spring app, there were, or there have been some authorization fine- grain authorization capabilities within Spring that helped you do maybe 80% of what it is you want to do. So that's also a possibility, the non- standard route.

Vittorio Bertocci: I love the pragmatic angle. And so many times you hear cargo cult standard applications. And instead, I love your pragmatic approach as in there is something already there, which does what you need, go for it. Fantastic. I 400% degree. So this was an incredibly interesting chat. I think that this space is enormous and so is your knowledge about it. So please expect the listeners of the episode to ask for specific drill downs. And which probably means that I'll try to get you again on the show for the time being-

David Brosard: Sure.

Vittorio Bertocci: ...Thank you so much for being a so nice to talk with us for a good 30 minutes.

David Brosard: Thanks Vittorio.

Vittorio Bertocci: Great. And thanks everyone for tuning in. Thanks everyone for tuning in. Until the next time. Thanks everyone for listening. Subscribe to our podcast on your favorite app on IdentityUnlocked. com. Until next time, I'm Vittorio Bertocci and this is Identity, Unlocked. Music for this podcast composed and performed by Marcelo Markovski. Identity, Unlocked is powered by Auth0. Copyright 2020. Auth0, Inc. All rights reserved.