Those of you that know me, I've been working around in the identity industry for many years now, actually I can actually say this I've been working around since the last century, but one of the things that I've always been pretty passionate about is the issue of authorization, the issue of access control, right? And even though most of the time that we play around with identity, there's a whole slew of things that we start working with, right? The, the, the job of gaining access starts with some level of identification, depending on what we're giving out. It may simply be enter your email address, and I know who you are, or maybe there's a really strong identification process. We go into anybody that attended Andrew Hughes's presentation can go into that sort of in depth. And then there's the process of authentication, which is making sure that every time that person comes back, we're pretty sure that it's the same person, but none of that actually matters unless we are going to use that information to enforce access control.
And so during this week, I've been listening to a bunch of presentations and the term policy has come up several times. I think I counted four different presentations that I was sitting in, that it came up with that idea of policy and policy is one of those things that I've wanted to, or been focused on for quite a long time. So when we sort of start looking at it, let's start off with the process of looking at the authentication versus authorization on the authentication side. I think we've done a pretty good job, right? We we've, we'll go back and have a look at that in a minute, but in authentication, we are doing a pretty good job of identifying who the person is. And we are putting in risk based and dynamic authentication and all sorts of things that we are fairly confident that we know who the person is.
All of the software products that we are dealing with generally put authorization bolted onto the side of your authentication server. And, you know, we, we have some access control pieces that tie into authorization, but to get to this point in the authentication chain, it's been a long, hard slog. And so I just wanna walk through some of that. Hopefully I don't have any answers for us about this policy question, but hopefully I can give us a little bit of a roadmap that we can look back and see how we got here. And some things that did work, things that didn't work and, and the way that it sort of evolved its way into the problem. So sort of going into that, I'm gonna take us down a rabbit hole. Some imagine that we are falling all the way back into 1994. So in 1994, at the time I was working at Netscape, we, we were doing LDAP service at the time and Netscape, we were sort of looking at how do we handle this problem of authentication.
It was a very different problem than we have now. Everything was a silo. Every single application was built completely in isolation. They all dealt with their own thing. And the whole model of dealing with silos is, you know, we talk about it now, but boy, that was what we had to deal with. And so when we went into each of these apps, our goals were actually quite low. We had a relatively low bar to get into each app was a silo. Let's ignore SAS for the moment because SAS wasn't even a thing yet. Right? We were dealing with server based apps. And the thing that we were trying to do was to say to them, don't store attributes yourself, don't store them in a database or a file system or something like that. Use a central repository to store the attributes around your user and the authentication information.
And by authentication, I mean a password. And if we were lucky, it was an encrypted password, but generally it was just a password, right? Each app did their own authentication. Each app was responsible for its own credentials. Each app was responsible for its own set of users and managing those users. Right? And the goal that we had at the time was to simply try and say, can we centralize these attributes? The whole idea that we could actually get to the kind of authentication that we have today was kind of a, a dream that we had on Friday night BES, right? Because each app wanted to be able to do their own thing. And the reason for that, we heard back from developers, right? Moving authentication out of the app was a battle that we fought with every single app. Why? Well, there's no way that they wanted to let it out because the developers want to control the login process.
They want to control how it works. They measured how quickly you could get into the app in an extra couple of seconds for a process that they didn't control. No, that's not good enough. We've gotta be able to do it. And then they started talking about availability. We don't want our app to be dependent on some random piece of identity software. That's gonna do our authentication. We don't know if it's gonna be around. We don't know if it's gonna be up right. Availability, reliability, the fragility of simply connecting to another server with reasons not to be able to do that slowly. We started moving that away. We managed to leave them the UI, but we moved the credentials into LDAP and we started using an LDAP bind. And so we let LDAP actually do the authentication and just let the apps handle the UI. Once we were able to move the UI into the authentication process, all sorts of new things became possible.
Everything we've looked at in this conference, multifactor authentication, risk based authentication, even Federation, right, became possible because we were managing the authentication. We were managing really determining who the user was centrally in a central service. And that sort of became the standard that's where we are now. Right. But it was a long, slow, drawn out process to get there. It didn't hurt that SAS sort of came into the game as well. And I'll come back to SAS in a couple of minutes, but let's look at the same parallel as we start looking at authorization. So authorization is basically, can the user do this action? And there's typically three, maybe four different ways. We can go into this and we can break them down that can probably break them down into some extra ones. But there's sort of three typical ways we dive into this. The first way is we have some form of agent.
We put something into the process between the application and the user, and we intercept their request. We do some form of URL processing and regular expression processing. And what I call, you know, withered processing, we wear the long right robes and we get to write, write only expressions to be able to match them open policy agent. Another example of this, it's little easier to be able to do those, but they parse out the URL and they say, can the web browser access this URL? It's a relatively low bar for access control, but heck it works right in general, it tends to not be very specific. It tends to be maybe a few of those URLs per application. And in many cases, can they access the application or not? On the other hand, we can put a bit more work in the application and we can use bare tokens O worth two, right?
We can issue tokens and the browser comes up, presents this token to an end point. They have a look at the scope and see if you can get in and we can make the decision. Yes, you can get in or no, you can't. And we have that process. It's a little bit more fine grain. We can deal with different scopes. I'll come back to those scopes in a second. And then the third one is where it's a little more tightly integrated. The easy one is where you've got an application that just ties in with LDAP, right? It, it says, point me to your LDAP server and put users into groups. And we'll just check is member of group. Maybe it's a little more than that, right? And they're gonna say, okay, if we synchronize the users up, we've got a whole bunch of entitlements inside of our app.
So if we synchronize up the users, you can then manage those entitlements. But all of these different methods, all of these different things that we are doing to maintain or to try and perform access control, define how it's done. That's the act of enforcement. And it's cool because it's technology. I love it, right? This is the technology that we can go and play around with requests and responses and do all of these things. How we come to the access control decision is sort of a little more gray area. It's generally defined by configuration. We have to open up a window somewhere and dive down into a bunch of check boxes and add a, a click to allow or a click to deny or type in some URL. There really isn't any defined policy that tells us who gets to access. What maybe if we do have a policy, it's something that the manager has said to us that only people in engineering should be able to access these documents.
Okay. So there's a defined policy, but in terms of the access control system, that's a verbal policy. It doesn't really exist, right? The whole idea of having centralized authorization, something that we can go back and see what can users do is sort of not there. Right? We also have a second problem with authorization and that is this generally two parallel tracks. There's the web based authorization, which is a policy agent that says you can get into this app or not. And then once you get into the app and I'm gonna quote here, I'm probably wrong. But on, on Tuesday morning in one of the keynote things, we were talking about SAP. And I think the number that was on the screen was a million different entitlements. Those are not managed by our identity system. Those are managed internally in the app. And so there's two different places, two different systems, two different ways that we have to control what the user can actually do and how they can work.
And ultimately this comes down to configuration, not policy. Somebody has to go in and configure some access control rule somewhere, right? So what to stop us from doing a centralized authorization? Well, it's the same things that happened 25 years ago when we were looking at authentication, right? From a developer's perspective, I don't want to have to depend on a separate server. It's not fast enough. I can't make requests fast enough to satisfy my really complex needs. And even if I could, the really complex decisions that I have to make, can't be handled by an authorization server. It's too complex for me to do that. And it's probably not reliable enough and I don't want to allow my app to go down. Right? And so the result is at least home built apps, many of these apps perform their own authorization with their own configuration. And if anything, we integrate at the edge, we, we put an agent in front and we say, oh yes, these users can get into the application and everything else is handled by the application itself.
So the challenges we have to managing policy, right, is that exact process, each app has its own access control that it has to deal with. On top of that, let's bring SAS into the picture, right? SAS, we don't control the app. We didn't write the app. We don't have the code to the app. It's not our app. And so think Salesforce think Workday, these kinds of apps, we can't go in there and actually control their entitlements. Right. Which can be a lot, as we said, SAP was a million. Anybody who's gone into configure Salesforce knows that there's more than, than tens of thousands of that around in there that you can go in and configure. Those entitlements are managed in isolation by each app. And that's the problem that we have to try and solve if we put policy into place, because policy means we can define here's what my users should be able to do, and let's make the apps actually work with that.
So how can we get there? Well, the first answer is I've got no idea. However, there are some things that we can try and deal with. Can standards help us? Maybe I hope we can do some standards here because if we're gonna interoperate, what would be really cool is to be able to take our policy from one vendor and give it to a different vendor and have the same access control being done to the underlying resources, without having to write pages and pages and pages and pages and pages of access control rules, or the, the configuration necessary to access those. Right? So there's a couple of standards in history that I want to put up. And I'm very proud of this slide. I'm proud of this slide because it's the second one this week that I've seen that has Zal up on the slide. Now, normally when I put Zal up on the slide, everybody laughs at me and points at me and says, why are you doing that?
But there's an interesting part here, SAML and Zal. They were about the same time. They were both done sort of 2007 ish somewhere around about that timeframe. They were both very complex. They were both XML based. Zack mode was cool, extended access control, markup, language, extensible, access control, markup language. It introduced a whole bunch of terms to us like policy decision point policy, information, point policy enforcement point and all of these kinds of things. It expanded our grammar, but what happened? Samuel worked well kind of, it was adopted by government. However it evolved. And if you have a look and I know there's probably several people looking at me right now saying really you're gonna go from SAML to open ID connect and say, it's an Evolv it's evolving. Yes. Have a look at what you can do in open ID connect. Most of the things that can be done in Sam are also able to be done in open ID connect, except it's easier.
It's simpler. It's really only looking at the things that we actually used. Right. And it gave us a functional authentication standard. On the other side, we've got Zal it had many problems. Anybody that would like to share, well, it won't be one beer. It'll be several beers. We can talk about the things that were wrong with it. And I'll happily go and spend that time. But probably the single biggest mistake that it made. And this is one that we cannot repeat. The mistake that it made was it tried to look at a policy definition, language and the evaluation or the execution environment and put the two together. And it tried to define them both together. Right? We don't want to do that because the underlying execution environment can change radically. So when we talk about policy policy should be encoding our business requirements regardless of how we en enforce that access control underneath, we may well change it.
We may use agents. We may use OAuth. We may have dynamically evaluated policy. Doesn't matter. As long as the policy enables us to define who has access to what resources that policy should be simple. And I use the term simple here relatively, right? Because it's going to be complex because policy by definition is complex, but it should be simple to understand. We should be able to validate against it. Wouldn't it be nice if we could audit it? I dunno whether we can get there, but that's really where the policy is so that we can define who can do what to what targets or to what actions on what targets and on top of that, if we can be interoperable, right? So that different vendors can utilize the same policy. Wow. That would really be cool. So let's bring our friend SAS into the picture. Again, probably 10 years ago at an RSA conference, I was having a beer, many great things happen over a beer.
I was having a beer with Chuck Morr from Salesforce. And I was saying, wouldn't it be cool if Salesforce could call back to our rules engine in order to do policy evaluation? Well, that was his response, right? The, the no way was he going to take the performance, the reliability, the availability of Salesforce, and say, sure, we'll make a random call off to one of our providers to do policy evaluation. However, let's rephrase that. Let's look at the process of, well, maybe they don't have to call out to us, but maybe if we have a consistent language to define what the policy could be, our policy management can, I don't know, upload, download, cross load, send that policy information to assess application and we can manage it all in one place. So the job that we have to get there is not an easy task.
I'm not pretending that I have an answer to it, but if we can get an easy to manage an easy to understand definition of policy, that can be understood by the business, not the text, because we can go in and change all sorts of bit fields and attributes and all sorts of things in the underlying enforcement mechanism. But it doesn't actually tell us why we are making that decision. And so if the, the business can understand it, right, it lowers their complexity and take us back to Tuesday mornings keynote, the panel that we had up here, the thing that they asked for lower complexity, right? And it makes entitlement management more transparent, but it's gonna take all of us, both the tech and the business to define what that language needs to look like. And that's the goal of standards organizations. So please get involved and hopefully we can get somewhere to get policy into access control. Thank you.
