We're gonna start. Hi, my name's Alexei Babin. I'm the c o at three Edges. We are startup based in Western Canada, mainly funded so far by Nly Identity Management, a company also based in Canada. We are a cloud platform, a no-code platform to do graph based access control. And that's what we're gonna talk about today. But before doing so, I just want us to start with a little quiz just to see where we're at. This is gonna be a bit of an experiment for me. I don't know. We'll see how that goes. This will be interesting. I'm gonna show you a picture and ask you two questions. Alright? Okay. He goes, here's the picture. I give you a few seconds to read this. The hint, start over there. Work your way here. Good. First question, if you can read and understand this, can you raise your hand please?
Everybody? Awesome. Now, if you are a graph expert, can you keep your hand up? Okay. A couple of people. Okay. So what this tells us is that you don't have to be a graph expert to understand a graph, which is what this is. Please bear that in mind. So we'll start our little exploration here with Zanzibar and fine grain access control. All right, so disclaimer, this is going to be a little opinionated, but we'll see. So for that, we'll start in 2019 with the publication of Google Zanzibar. Very influential paper, right? Zanzibar is a system that uses tuple. Tuple are strings like those, which in effect relate a user to an object. What the string means is that the user can access the object, the type of access is given by the relationship. Now, some people have pointed out that this can be represented as a graph, and for sure you can represent this like so.
This is also called fine grain access control, because the object can be as granular as you need it to be. Could be down to, you know, a database if you need it. Now, here I need to set something straight. The appis. Back in 1997, the WS C published a specification called the resource description Framework rdf. Has anybody heard of rdf? Yeah, a few people. Okay, for everybody else, well, this was the goal of that was to describe the worldwide web, pretty ambitious goal. In that specification, they define triples as subjects, predicate objects, and they define and they actually say that this can be represented as a graph. And to this day, RDF graphs are still used. So as you can see, Google didn't really invent the wheel there. Anyway, end of bra, end of rent, go back to Zanzibar. Here's an example of Zanzibar taken straight from the article.
On the right side you'll see some tuple. Let's see if this laser works. Yeah, so here's what they mean. The first tuple means user 10 is an owner of Doc Rimi. Then user 11 is a member of Group Nang. Me, members of Group N are viewers of Doc Rimi. And Doc Rimi is in folder A. All right, here's how you could represent that as a graph. I'll let you decide which of these is easier to read and understand and maybe even maintain. Now, just wanna point out that Zanzibar and FGA systems are actually used. This thing, they don't use that. That is a fancy side effect. Some implementations do show that, but it's not really actually used. Now, some people mention that this is relationship-based access control reback. So let's have a look at Reback next. To understand Reback, we have to take our time machine and go back 12 years before Zanzibar we're back in two, 2007. That's when the term Reback was first coined by Carrie. Kates was then working at ca and she noticed that in the nascent networks, networks, social networks out there, Facebook and LinkedIn, we needed a new kind of of access control based on the relationships between the entities. And she called that system reback, relationship-based access control. So again, REBACK is not a new thing. Anyway, here's an example of reback. You mind recognize this?
This is role-based access control expressed as reback as a graph. Pretty simple, right? This is a model actually, it's not data. A model is what the graph would look like when, when viewed from a very high standpoint. Or another way to look at it is what the graph looks like. If there's only one instance of every possible node and relationship. Here's some sample data as an example that complies to the model. We have some users over here, some roll. You see we have a raw hierarchy and some objects here that we want to protect. The way a reback works is we usually find a path in the graph from the subject to the object. So let's take an example. Let's say we want to to see what user Alice over there has access to. What we're going to do is find all the possible paths from Alice to the objects.
Here we go. We have two possible paths through the role, sorry. So the role admin, she gets access to the HR database. So the role hr, she gets access to the HR app. Therefore, Alice has access to these two things. Simple. How about Bob Down here, there's only one single pass we can follow from Bob to an object. Therefore, Bob only has access to the HR app. That's it. So then well, I mean reback is more generic than just doing rback. You can do anything with reback that you can express with relationships, which is a lot. Anyway. So what then of k A, you might have heard of K, a knowledge-based access control. Well, the idea here is to use a knowledge graph to do reback essentially, but I'm going to argue that any graph encapsulates at least some knowledge. Therefore, K a and rebar are essentially the same thing.
Anyway, moving on a little blurb about aback and p a. We hear a lot about that because some system actually use graphs in the backend. They won't tell you necessarily, but some, some do. Anyway, as you know, for aback, we have to go back four more years. We're now in 2003 zal. All these specifications don't need to go much into details there, but he's just a little bit on on aac. AAC uses attribute values and they could be any attributes, but typically attributes fall into those four categories. User attributes, object attributes, contextual conditions, and actions. So let's take this rule as an example. In the banking world, we can see a bank that bank tellers can access any bank account located at the branch. They work out weekdays during business hours. That's a policy we need to enforce. Here's how APAC would do it. We would define those three conditions here.
A subject attributes the subject need to have a role of teller and say B, in a branch, the object need to have a type of account and the same branch as the user and the context will provide us time of day and all that. At runtime, a user tries to access a bank account. We look at the action and then we look at all these properties at this policy that we've defined and we derive a conclusion. Simple. Now feedback. I know there's been a lot of talk. I think myself that feedback and AAC are kind of the same thing. I know that p a provides the management level and all that, but if you look at the zal specification, for example, policies are there. So we're building policies with rules based on attributes. So I think it's the same thing in the end. But anyway, you can add business rules and all that to your payback. So, so far I've talked about what we've done so far in the 20th century. Yeah, if you don't agree with that, talk to me afterwards. We can, we can have a chat.
So what are we gonna do next? Well, next we need to talk about n g or NextGen Access control. Has anybody ever heard of n g or no? No one. Oh yeah. Okay, cool. We should talk afterwards. So n g is actually a standard, but look at that. It's an Nancy standard. It's interesting. It's not a group that we usually hear about in our sphere. It's not I etf, you know, open ID foundation and all of those. ANZ is the people who created sql, I mean who standardized sql. So this standard actually is pretty recent. The last version and publication dates, bike dates back just a couple of years ago. So brand new what end end gap proposes is a base model, kind of like zakk as well as a graph model. Essentially n g is a back with graphs. Just to summarize it, here's a quick look at what the ANGA architecture looks like.
You will probably recognize some of these things. They're exactly the same as the ZK speck, you know, the policy enforcement point, your policy decision point, all that. But there's a couple new elements in here. The wrap, the resource access point is like a connector that actually interfaces with the resource you're protecting. The idea here is that the process making the request doesn't necessarily know where the resource is located and it's the role of the wrap to figure it out. Interestingly here, this epp, this event processing point is an optional component, but it's there to handle events and there are mainly useful two things. The most common use for this is to process contextual events. Something like time of day. For example, when it's 4:00 PM something happens or when it's Sunday something happens, another use for these shared signals. We can now through this architecture actually react to something that happens in real time somewhere else.
So as you can see, it's quite a forward thinking architecture. It's part of the standard. So let's have a look at what n g does using our our good old policy here, the bank teller. So let's take a deep breath. Here's the n g model. Ooh, it's actually not that bad. There's only five types of nodes here. There are user nodes, user attributes, object nodes, object attributes, and a couple of policies right here. Actually this graph is divided in two sub graphs. We have, oops, yeah, we have a subject graph. Sub graph. It's a dag a directed a CCL graph. What that means is that all arrows point in the same direction and there's no loops. There's also an object sub graph between the two. We have special types of relationships called associations and these provides access rights from users to objects. Finally here we have policies and we'll get back to that. So how does this work at runtime? At runtime, we'll use an algorithm called preview full citation up here for the research paper that published that. This is a linear algorithm so it'll scale well.
So preview has three high level steps. It's actually pretty simple and it users reback as you'll see here. We wanna answer the question, what does one user have access to say this guy over here, user one. So the first step is, we'll, we'll F is we'll find candidate objects. What objects can this user potentially access? So for that, we'll find a path from the user to the objects going through the associations. Here we go. And here we go. We find that a couple of objects are potentially accessible by this user with by the way, this action crud create really update, delete. Secondly, once we have these objects, we wanna find what policies are required by these objects. So from from the objects we'll find a pass to the policies. Here we go from account one, we find that we need a role policy with the value of teller and a branch policy with the value of branch one.
Similarly, from the account two, we have role teller and branch two. Right? Last step is we wanna see which of these policies the user attribute actually satisfy. So this time we start from the user again, but we're going to find a pass to the roles, sorry, to the policies. So here we only have two past possible. So the user satisfies the rule policy with the value of teller and the branch policy with the value of branch one. We can now compare and we can see that the user only satisfies account one requirements, therefore the user can only access account one.
This is one missing point, one missing thing here. What about time of day? Well, as I mentioned, we can use events for this. So we can define four events. When it's 4:00 PM we can delete this relationship here, this association, this in effect invalidates the role policy and prevents the user from accessing account one at 9:00 AM the next day we can recreate it. So we can toggle this like that based on any kind of event. Okay, event risk, event, what have you. That's it. So in conclusion, why would you even do that? Why go through the trouble of having graphs? I try to summarize this in this table. A bunch of criteria here, all these approaches and what I think the value is. So if you look for example at fga, why? It's probably good for speed and volume, but you're gonna end up with a lot of two.
So it's gonna be really hard to manage. I think it's not gonna be easy for a business user and environmental conditions, well you can't do that in a triple. You'll need something else to create those twos in real time. So anyway, not that easy. So if you have environmental conditions in your policies, then you really only have those two options here if you need to enable your business users. Now, as we've seen, we don't need to be a graph expert to understand graphs and therefore anybody should be able to make sense of a graph. Some implementations of AAC are business friendly, so can look for that. Depends on the tooling provability. Like you wanna make sure that your rules actually do what you're expecting them to do. Well in a graph you can just follow the path and it's right there as opposed to going through code or through a bunch of two poles. Overall, while I think the graph approaches are the best. That's it. That's all I have for you. If you have any more, if you're curious and in one more details there's a white paper you published, feel free to download that and if you have any questions, looks like you have three minutes.
Yeah, thanks.
First of all, fascinating visualization for me as a mathematician. Easy, you know?
Nice. Thanks.
Continue, continue. After what we were discussing before, later, humanly seems to me that, and I want to hear your opinion about this, it seems to me that some of the EPP story could be actual business task, which is an event. Absolutely. Are you, do you have examples of, as I understand you are doing those graphs as a, as a partner. Yeah. Do you have an example of such things or experience with some of the customers doing something like that?
Well, business events like moving job des, moving jobs, being hired, being you know, fired or sign task or something. Exactly. I mean that's, that's what I mean. Like for example in Cape you have those token claim changes events, you can probably use that. Anything that changes in the user's attributes or in the user's context can trigger a change in the graph in real time. And whenever access is requested, as you can see, we can really toggle easily those relationships. That kind of answer it.
Hey, so just a short question. What's your thoughts around governance on this, right? Review certification, like auditing around this compared to the other solutions? Because like AAC and so on, we've had a lot of talks and discussion around policies, policies and little discussion around the data quality also. Right? But what's your thought general?
Well, as you can see we have policy nodes in there. So we do have policies now. I guess it depends on the tooling that you have to go for that. But this, this example I showed was just one use case. I guess you may have several of those and it's sold the way, the way you can manage that depends on the tooling as well. But it's kind of the same thing as feedback in that, in that case you, you would look at the policies and just making sure that, you know, following the past you can actually validate that the rule make does what it does, what it's supposed to do, let's say. So it's very comparable to what you do with AAC or B back. It's kind of a, a more generic, it's kind of a rule-based system really. So very similar.
We have time for maybe one or two questions. Anyone else?
Nope. Lunch is waiting. Let's get lunch. Yeah. Thank you. Thank you.
