Someone say yes. Yes, okay, we got a thumbs up in the back there.
Okay, so my name's Allan Foster. For those of you that don't know me, I was one of the founders of ForgeRock. And I've been playing with access control for 30 years. The first time I started with access control is we got to stand up here and say, the solution is going to be LDAP. So we've come a long way. But we started having a discussion around, here's the latest silver bullet, PBAC for access control. So I want to warn you up front, I don't have a product to sell. I don't have a solution to tell you how to do it.
Hopefully as we go through here, I'm going to bring up a bunch of questions and things that you can start thinking about what we need to do when we start integrating. And as I say, I have a presentation full of yes buts. What that means is that pretty much every slide somebody in the audience here is going to look at it and say, yes, but we do this or we do that. And it's not necessarily because a lot of the acronyms and a lot of the things we look at are going to be fuzzy in their definitions.
They are, we can talk about them. But the one joy that I have because I get to stand up here is I get to draw the lines. So I get to say what they are and we can argue about them later on. But as we go into looking at access control, wow, it really does just go by itself. I'm afraid of it now. So we've just gone out, we've gotten ourselves at whatever the identity system of choice is, right? They've sold it to you, you've got a great system, you've deployed it, you've got all of your user management and a nice central repository and all of these things are done. I'm going to be afraid now.
So we've got all of these things in place and what we now want to try and do is start giving access to applications, right? This is where the rubber meets the road. We've got to try and give access to the application. So I started thinking about this. And when we start talking about legacy apps, there's sort of three things I want to try and address. They don't go together very well. I wish there was a nice way to have a good story to go through with them.
They don't go together very well, but each one of them has some things that are really important and that we should sort of think about in context when we start looking at them. So the first piece is this whole legacy thing. What do we mean by legacy system integration? The reality is almost every single one of them is a hack.
We, as system integrators, we all know. We can stand up and we can say, oh sure, we can do that. We can hook up your XYZ process into this and make it work. And the way, it keeps jumping at me, the way that we do that is possibly with some Perl scripts or possibly some Python scripts or maybe we've got some adapters that go into it. When we look at legacy, no, no, come back. I'm gonna stop touching that because it does go by itself. When we look at legacy system, this comes from Wikipedia, whole lot of words in there, but there's a few things that I think are really important to remember.
Legacy was not designed to fit in with the software that we're now installing. It's old, whether it's a system or an application or a program, it's old. It's from something we invested some time ago. We're still using it. Probably it's, oops, is that my headphone? Probably it still works because it's still in use and it's doing probably most of what we need. But the reality, and we all know this, it probably needs to be replaced. Is that me making that noise? It probably needs to be replaced. And so that's one of the questions we've got when we start going into the integration part.
We can actually look at that. No, no, come back. We can actually come back and look at the question of do we actually need to integrate it? There's a whole slew of systems in there where only two people log in and they probably don't need SSO on it. And can we just leave it out of the picture?
Okay, we've decided we can't. So the next question we wanna start thinking about is how much? What do we actually need to do with it? So when I think about this, the first, the easy, the sort of table stakes that we go into it is we'll throw up something like this. If you're not allowed, no, not there, this one. If you're not allowed to get to it, we'll throw you to a 404 page or we'll throw you to some kind of page that says you're accessing a system you're not allowed to. It's intercepting the web browser and you're done. We don't really care what's happening.
We don't care what's happening inside the app. We simply care as to whether you can get there or not. And it turns out that's a relatively easy thing to decide. We can get to that piece. A little bit further, we start thinking about do we actually, do we care about the underlying data? Do we wanna put access controls on the data? The good news there is it's probably already there if you're using Oracle or one of the databases. You've got a set of access control down to the underlying data. Or you can expose the data using some kind of, no, come back, web-based API.
We can put some access control on that. The good news about that is we're building something new. And if we're building something new, we can build it specifically to interact with the capabilities of our brand spanking new identity system that we've got. The third piece, which is really hard. Everybody wants to do it, but it's really hard to do. And that's trying to provide functional access control to a system that doesn't really have it already. Things like separation of duties or areas of control or some kind of fine-grained access control to the underlying business-level data.
Keep this in mind, because we're gonna come back to this one in a minute as to how we can get here. But this is much harder to do, because at the level that we're trying to enforce, we don't know these things. We've gotta try and infer them. That evil hack that I was talking about a little while ago, that's where we end up doing it. So put that piece on hold for the moment, and let's come back in and talk about what do we have to work with.
Now, here's a surprise for everybody in the room. You thought we were gonna get through an access control discussion without Zackmull on the screen, and we get Zackmull on the screen. I'm not telling you Zackmull is the right way to go. But Zackmull did introduce a few really interesting domains that are important for us to think about in integration with apps. And that's these ones down at the bottom here. Let's start over there on the right. The policy information point, where we've just spent all of that time and money putting in our brand new identity system.
And that's our information point, right? Where are we getting the attributes from? But these other three are gonna determine how you can do the integration. So the first one is the decision point, the policy decision point. Where is the decision being made? Or more importantly, how much control do you have over that decision? If it's embedded, right, something inside of the system, anybody use Salesforce, right, where you've got a really complex decision point, but it's deep inside of the application, and you can't really get in and do anything with it?
No, that one, there we go. Hopefully what we're trying to do is to use an external decision point, the one that we've just installed. But they sort of don't know how to talk to each other. And that's sort of where a lot of the evil hacks that we were talking about comes into it. Because tied to the decision point, once you have a decision, we have an enforcement point.
Which is, how are we actually going to enforce, no, how are we actually going to enforce that decision? Mostly, it's probably gonna be a web agent, or possibly some kind of gateway, or something like that. If you've got a very sophisticated decision point inside the application, they're probably going to be legacy code that's doing that enforcement, right? It's inside the app itself. And if you've got an app, legacy code, we probably can't go in and change it. So it's difficult for us to get to those points.
And the final one, which we don't think about a lot, but it's actually a really powerful integration point, is the administration point. This is, how do you create, manage, and delete policies inside of the system?
So, one of the ways we can integrate is we can start playing around with the policies and let the internal application start dealing with things. And so our access control could well focus on, come back, provisioning on the actual underlying policies. And I'm gonna come back to that one in a minute as well. Which brings us to the different forms of policy language. The access control methods. My personal little joke, it's a Starbucks.
Star, Starbucks, Starbucks. So we've got all of the different ABAC, PBAC, RBAC, all the different access controls. And they all do the same thing, right? The only thing that they are there for is so that we can take a structure around defining the policy that we wanna get enforced. But they are, they do have some different focuses. So let's sort of look at them quickly. ACIs and ACLs.
Boring, it's a list of users. List of users can say you can come in through the door. We still use them a lot, right?
This is, anybody's got one of those electronic doors, door locks on their front door? What do you have in there is a list of user IDs that can come into it. Most badging systems is an ACL list. Anybody who uses SSH as a file somewhere that has an ACL. It's simple, it's easy, it's coarse grained. Doesn't scale. And it's not really policy other than can you do this?
Oh, it's Alan, he must be allowed to do it. So we add some more to that. This got really, really complex. Imagine having to deal with 10,000 user IDs in a small business and have to worry about each and every user ID. So we got more complex. We went to characteristic-based, RBAC. Role-based access control. It's too hard for us to remember everybody's name. We'll just remember what they do. And we'll give them a role. We forgot to keep track of that. So has anybody been in the directory where there are probably more roles than there are users?
Right, yeah, because we invented a role and then we're not quite sure what it was used for and we shouldn't reuse it. So we'll create another one just like it and you end up getting all of these roles.
Oh, and then our UK roles, our UK roles and our US roles need to be treated differently. And we've only got one role. So now we have admin underbar UK underbar Manchester and admin underbar UK underbar London as being separate roles. We can fix that. We'll just go to ABAC where we'll say we'll have multiple attributes, right? We'll add more but we're looking at attributes of the underlying identity. Still characteristics. Probably one of the places where if David was here we would talk about the yes but because generally it tends to be user focused or at least attributes about users.
But you can have attributes about targets or things you're protecting or other things. But generally it tends to be user based. And then we sort of start talking about entitlements. And I have a problem with entitlements. Are you coming to chase me away?
No, I'm not. Let's see if that one's gonna be... I'm gonna make a mistake here. I know I am. So entitlements, can you hear?
Ooh, ooh, that's better. Come back. Entitlements gives you eligibility to do something. It doesn't say you can do it. It just says that you're eligible to do it. And the problem that I've got is kind of like having a badge, right? You can walk up to the door and you can open the door. But actually making the decision is based on this eligibility that was determined earlier on when you were authenticated or possibly even before that when you were actually provisioned, right?
And to me, the really interesting stuff is changing in the environment or changing in signals right now. So we generally wave that away magically and say, oh, well, that's sort of out of scope. That has to be handled at the enforcement point to do the additional checking. Very often it's what we see when you have tokens, bringing up tokens that have already been issued and you're trying to map into that. We have policy based.
Okay, it's a thing. The reality is all of these different access control methods are fundamentally defining a policy of what we want to enforce. But what PBAC really does for us is it gives us a bit more of an abstraction layer. It means we can start talking about what we want to enforce rather than how we want to enforce it. It probably helps us get around that role problem where we've got so many gazillion different roles, right? We can sort of now get down, no. We can now get down into what we want to enforce and start bringing in real time things.
Signals or various other kinds of state into that rules engine to start making real time decisions. So there's actually some useful things we can get in here. The challenge is gonna be how do we integrate them in and we'll come back into that in a second, right? Another one, this is if you get a bunch of access control people together over probably alcohol, we'll start talking about what are business logic and what is access control.
Boy, that line moves all over the place, right? It's functional or role separation, something that should be enforced at the access control layer or is that actually a business logic layer? The answer is yes, it's both, right? We do it all over the place in that.
But no, how did we get here? There we go, that's where we are.
Generally, these are enforced, especially if you've got a built in or an embedded PDP. Generally, they're enforced down at that layer. So does PBAC help?
Well, yes, it does. It gives us an abstraction layer. It gives us the ability to be able to express what we want to achieve without being too explicit when we're defining the policy. When we're defining the policy as to how we're going to achieve it. So it does give us that level of abstraction and that makes it easier for us to actually go in and implement it.
So, no, come back, stay there. I think every time you wave this around, it just jumps over. Going back to that first problem we had with the integration. What are we actually, how are we gonna do this? And the problem is there is no easy solution. It's not a nice, easy plug and play way to do it. Every app is gonna be different. Every app is, at best, creative software engineering and at worst, a hack to try and get it to fit in together. And we start looking at it, how much do we need to do? How much is enough? Is just preventing access to the app enough?
I'm not sure that the business would accept just access to Salesforce or not. You know, that's probably not enough access control to really support.
However, there's some other apps. Well, yeah, just getting access to something. If the appropriate people can get to it, they can do their job, right? What about domain objects? Salesforce, absolutely. You wanna be down into the business objects inside of Salesforce. So almost every integration, that time it did it automatically and it looked like I planned it. Almost every integration is going to be a hybrid integration. We're going to try and leverage the decisions internally to enforce probably domain level access control.
And we're gonna use our external brand spanking new IAM system to enforce access at the network layer or access at the application layer and try and combine those in. And if we go back to the ZACML slide, when we were talking about the policy administration point, this is a really useful way for us to interact with the internal decision point to set up the policies, including interesting things that we sort of used in federation like mapping. We may not need to have a separate policy for every person. We may just be setting policies for roles and setting those up from our administration point.
But ultimately, we're going to combine these all together. And it's going to be, it's not pretty, right? Anybody who's been down in the trenches to put these in, the mechanics of doing this is not pretty. So the initial premise that we were looking at, does PBAC policy-based access control actually help us?
Well, I think in the net run of things, yes. It's probably one of the useful tools in our toolbox. And it does give us some things that we can work with. Abstraction is always good because we can hide multiple layers of magic behind abstractions. Abstractions and magic are great things for us to be able to do. With hiding and abstractions, we get more flexibility. We can decide where something is going to be enforced, how it's going to be enforced, and we can set things up in the policy layer and the administration layer to set the right policies to be in place.
We can also start integrating in some of the new dynamic kinds of information into the decision, like signals, right? So there's work being done in OIDF with the Auth Then user group for enforcement point interaction, with the signals group, where we're talking about getting real-time signals on things. It's kind of nice to make access control decisions based on whether this is a compromised or something that we saw during the authentication process. And so we can integrate in to each one of those different systems at the level that makes sense for that system.
Ultimately, I still would go back to slide number two. Really, we should be asking the question, are we trying to integrate into this legacy application, and shouldn't we be talking about upgrading that to a newer version that supports all of these things and supports some of our more standardized protocols and things like that? Because legacy integration is trying to go things which were not designed for this and bring them into that or into our new space. So you may disagree with many of the things that I've put on the slides, but they're at least things to think about.
I'm happy to have arguments. Hopefully, alcohol will be involved. It'll be a little later on. Happy to have arguments with it.
Hopefully, there's been some, so at least some thinking points. And thank you very much. Thank you. Thank you. Thank you. Thank you.
