About this talk
In this talk, Gabriel Manor discusses the future of authorization in software applications, drawing on his extensive experience in the cybersecurity and authorization field. He outlines the four major challenges currently faced in authorization: chaos, complexity, velocity, and user confidence. Gabriel emphasizes the need for structured approaches and frameworks to predict authorization trends, highlighting open-source tools and methodologies. By exploring historical programming trends and innovative authorization models, he advocates for a shift towards decentralized policy engines that can handle fine-grained access control using various authorization frameworks, such as role-based, attribute-based, and relationship-based access controls. Additionally, he presents domain-specific declarative languages as potential solutions to enhance developer experience while managing permissions.
Full transcript
[Music] ladies and Gentlemen please welcome our next speaker Gabriel Manor presenting the topic the future of authorization and applications can you see my slide oh great so I know you that you come to hear about the future but I'm sorry I'm going to disappoint you I don't know nothing about the future neither any one of you what I can do is try to predict future Trends but
we need a framework to predict friend future because if we're looking for example at a back for the Future movie we see today that many of the things there never happened and maybe will never happen in the future so my name is Gabriel and today I'm going to talk about a framework how to know or at least predict what will be in the future and specifically in
the authorization field my first credibility to predict the future is my work I'm working as a software development for since 2012 and somehow since 2015 I was around authorization I work on product that do authorization in the network I work on cyber security products on the authorization part how many of you develop authorization in their life sometime yeah that's many that's great Hello friends so um yeah
authorization is something that is probably part of every product at some level but in the last years I found that there are some trends that we need to follow and uh today I'm going to talk about it I'm working in a permid AOA startup again around authorization but I'm not going to talk about permit of course um I'm going to talk about in general the field some
open source tools so let's get started first I found or I IID didn't identify four problems that we have today in authorization the first one is the chaos every um good authorization uh implementation today in applications it start without any kind of order the second is the complexity of the permission we want to get in uh any application it is not anymore an admin and a user
it's much more complex we have too much data in our application to make make it simple the Velocity in the the the we ship our software on right we are delivering software every minute maybe and that's require permission change and that require better authorization in our application and the confidence that we want to have in our application and let's dive into each of these problems in details
so first one is the chos if we are looking back on a 2010 2015 application used to be one piece of code right I remember when I start to work our code base was 8 GB we manage it as files we deployed software as artifact as one large artifact into the not the cloud into a computer somewhere in a server form but today our application um incorporate
many many components it could be microservices uh in a microservice architecture but even in a monolith architecture we are modeling our software in a way that we have multi languages that we have multiple thirdparty services that we are using for example for data for monitoring for observability and in a way to streamline our permissions or our authorization service across all our component in our software we are
getting into chaos an admin in one service can be someone else in other service and it's not only that even inside those Services we are getting data from multiple points and that lead me to the second part the data that we are processing is not anymore a one database right when I started to work again and I'm goes back again and again in time but when I
started to work there was like a a stack that called wamp or lamp right we have PHP MySQL and Apache server and actually we have one place to store all our data we have one instance it was vertically replicated into multiple instances today when I'm starting application I'm consuming data from many many sources some of them in-house right I have my no sequel my MySQL my big
data instances my big query right and I also have data in third party Services maybe in elastic search maybe in um some other providers that allow me nowadays maybe llms this data led to what I call decision fatigue the more data that we have the more decision we need to make and this decision require more and more data in them to get calculated right the policies that
we are running on our data needs more and more decision calculation and that led it into decision fatigue because we say okay we want to keep a less privileged principle so we will not get this decision we will not just allow it to a particular set of user but that also create an experience problem right and then people just find a way to access or find a
way to perform operations so the data in our application also create um complexity in what we have and also we have the Velocity right so we are delivering as I said software every minutes every couple of minutes if you are a startup we can deliver 10 times a day to production every deliver maybe have some permission changes maybe have some configuration changes in the policies that we
want to enforce right where for example the admin can or cannot access but also if it doesn't have any kind of permission we want to make sure that we even we we not break anything in the data that actually used to calculate the um the permission request and last is the confidence that we have in our software and I think the main problem that we have in
that is the user requirement unfortunately the users of our software being sophisticated in technology from dayto day and they require some stuff and they also understand security so they come and say Hey I want this permission model in my application which not always possible but you still need to provide that and you still need to provide a good experience because if for example I have an if
statement in my code that decide what a user can or cannot do with a very special specific assertion of variables I want to streamline it to the user in a way that they can understand okay I'll assign role to someone and then you will be able to do something and this requirement also add a level of problem in the way that we do um authorization it's not
only that there are much more um users or stakeholder to our code and application right there is not anymore only developers that actually do something on the code there are devop there are platform there are security Engineers there are maybe even revops there are the bi people today require access to the code base because they want to add some analysis on the code and the application code
and we need to make sure that all these stakeholder do not break permission but also get the relevant permission I don't want my bi people get access to private user data but I want them to get access to metadata of the users right so these stakeholders around our application create another problem on the way that we are actually modeling permissions and for the last year U sorry
I'll go soon to that for the last year we have also tons of AI agent llms rugs a lot of services that actually require access to unstructured data in our application and this unstructured data we need to think on a better way we can give permissions for data that is not structured to any form in any other data in our applications just an example that everyone can
understand is Healthcare data so back in 2018 let's say before the covid and all the digital Health um um growth that we experienced the owner of my Healthcare data was the um insurer company maybe right the one that provide me the service they has all my Healthcare data and they own that and I trust them that they give access for someone to that today I'm the owner
of my data I can migrate in between provider I can ask for a very specific time that a nurse in an external place will get an access to my Healthcare data right so the user requirement today in authorization is not what it was 5 years ago the user that required authorization will just say Okay I want a different level for admin and a user today even in
consumer application user want to know hey I need access to my data but I want a a possibility to share part set or subset of this data with other user for a limited set of time right so this user requirement create a problem of confidence on what we are sharing or not applications with that problems in mind we need to predict the future right so what is
the best way to do then look on some other that experience problems and see how can I solve that I can I know what will be in the future if I look on other problem in software engineering and see how do they solve back then and try to implement them in authorization so one example I want to I love to take example from is programming languages back
in the 40 50 start computer start became people succeed to do something with silicon that can do calculation and then they understood we are going to a new level a level that we need to program these computers so they invented or not invented it was like a um evolution of the nature they find the binary language and then so-called machine code right that was the first language
that we use to program calculation machines at some point in time we have the problem of the Kos because there is a limitation how much you can write in binary code right and how much people can read so people started to uh create programming languages high level programming languages like C or for trend for specific sorry for specific usages at some point around the 80s or 90s
this uh code became more complex because computer became very um they were like everywhere and these languages were too complex and we started to create not me I born after but computer science started to create languages that influenced by Design patterns so for example C++ is a high level language that add the design pattern to solve this problem of complexity and C++ and after that Java and
languages that influence by design pattern started to have problem with velocity but they solved that with this design design pattern because if I'm creating for example an objectoriented language I can deliver software much faster because I can create solution that are fit for what I need to do now and for different solution I have different languages at some point we get to a point where this code
is not is hard with confidence because it has performance performance issue and I need to find a or computer people need to find a way to have programming langu languages that are specific for something solve a very narrow problem in a very good way and which is uh scientific proof or at least in any form of proof that uh it is no performance issu no re reability
issue Etc and then started to came domain specific declarative languages some of the most hardest problems in computer science today solved with domain specific programming languages the main example is HTML now I know it's not a program language yet it solve very hard problem how hard this is how how how long it take to write one div in assembly one div in C++ and one div in
HTML so first the level of the confidence in looking on that div and I'm not speaking about the complexity the CSS bring but the level of the confidence in looking at that div cannot you can compare it to the level of the confidence with some memory leak in any other language right and the velocity is very fast because it's a declarative language is just going again and
again into production in a way that I can very easy measure how how much I have a confidence in and velocity in my deliveries and of course it's a high level languages Etc so with these four problems and the solution like we want the structure for the chaos and Etc we will now try to see how can we Implement that in authorization to create better authorization product
and probably these Trends some of them already exist some of them exist but are not widely spread but it seems like that's the way authorization solution going to look in the near future this is just another example for domain specific declarative language for areas that are need this to solve these four problems not only HTML of course so first let's see how we can solve the chaos
by structure in authorization so first we need to think what are the level and we are the subjects that we are authorized if we're looking here in my right side but your left side we can see all the subjects that we want to authorize in our application let's start from the top we have the end users the end users for sure that's the user the main users
that we authorize right this is the most traditional one user in our application is someone that we want to authorize it's the first subject to authorize the second is internal users but some how developers so we have internal users in our applications for example the revops in the organization or any other internal stakeholder that want to configure permissions there are also user that we want to authorize
in a lower level than the end user but we still will need to authorize them with all the service to service and microservices and the cloud the services that uh interconnecting each other in Ingress also need a level of authorization we want to create policies that also authorize services to do not connect and to not perform think that they are not allowed so this is the third
subject and also a subsets of services is also infrastructure as code since we are deploying in a very automatic way in a very continuous way we want to make sure we are streamlining our policies and permissions in a way that all our services and infrastructur as code incorporate in our authorization service and of course you can I'll not go read everything here but but this subject is
something to start from we can do a we can have a structure of who we need to authorize what are the subjects we want to authorize after that we can start to model how do we want our policy system to look like so again let's start from the left side in the left side we want all our subjects all our architecture to be authorized with the same
set of policies in some application that hypothetic willing but in some application that start with a thing that we'll get to that later like polic as code and policy as graph we want all our configuration the rules so for example admin can access all document etc etc this one we want centralized in a way that all the services getting the same configuration to get decision based on
these policies we need policy engines right again in the abstract manner of policy engine but we want them to be decentralized because Services can be far from each other or in a different time zones or in a different guo zones or just services that they not supposed to get the data that related to each other so we want the policy engine to be decentralized and then consumed
by any part of our application so the best authorization service architecture that we can have that is ready for the future has centralized configuration decentralized engine that can consume by any part of our application that we in the levels before here for example if some of you familiar with domain driven design in domain driven design it's very easy to imagine that because we have the authorization domain
and the authorization domain as a subset of the decision engine in each one of the other domain but only the engine part of the authorization domain is the policy data and the configuration of our policies after we know how to solve the structure let's look on the design patterns that we have in authorization first design pattern is understand how authorization decision happen right every authorization decision ends
with a true or false value right we have a large something something and the result is allowed or denied but what incorporate this decision so there is three main parts the first one is the policy think about it in the abstract way like I mentioned like admin can access all document user can only read the old document right this is the policy then we have the data
the data is for example the names of the document that we might want calculate what is the name when the document started Etc and then we have the context context is the real-time data that drive the decision so for example what is the time now let's think about an example so we want all admin to perform um read operation on document that start with the uh on
let's say on all the PDF documents but only in daylight right so we have the policy config that allow the admin what we described we have the data which is the file type and we have the context what is the time now together a policy engine that incorporate these three pieces context data and policy can return us a decision right so this is the main design patter
understanding what incorporate a policy decision then we need to understand what is the decision type so that's right every decision type is allow or deny but at some form we want also to do maybe data filtering so if you want to read a whole table in the database we want to return what a user can or cannot read so some authorization decision could have more granularity than
that just allow or denied maybe it's allow or deny on subset and also um if we are thinking about the enforcement point we want to to get something that looks like that right a check function authorization Atomic authorization function that incorporate these three pieces or actually here it's four because we have the user the subject we have the action what they want to do and the resource
what they want to perform on and then we also able to pass some context like what is the time now or what is the time zone that the user application is using now right so this design pattern can solve most 99 99.5% of the authorization decision that we want to make so this is a great design pattern to start from and if we think about it we
can take it even to um a remote procedure call so we can have HTTP um call in our um policy engine or in our authorization service that always get this argument as a pure function always return the same value this way we are streamling one design pattern for all our services that consume those authorization service another kind of authorization decision that we might want to have is
called partial evaluation partial evaluation is something that just started to form now but it say we have some query languages right we have SQL we have graphql we have U maybe for big query some form of query languages what if we can instead of getting a decision of what a user is allowed or not allowed we can get a query that is fit for the specific user
so for example if an admin can read PDFs on daylight instead of returning allow or deny the policy engine will return SQL query that fit only to that right that filter the relevant data and then we can make sure that when we fetch the data from the database we get only what we want so this is another design pattern is less common than the just check function
but it's something we want to consider now after we have some design pattern how we code should look like let's talk about the velocity and how to solve that with framework this is the part that some of it not new some of it fairly new but the main framework we have in authorization today are for everything is end with a back which is based access control for
sure so we have policy based Access Control we'll get to everything later no worries and not just continue role based Access Control attribute based access control and relationship based Access Control let's start from what's so called course grain authorization policy based Access Control say I do not have too much data to make calculation of I do not have too much context to make calculation of but I
do have complex policies a common use case for policy based Access Control if any of you use uh infrastructure as code tools that check if the infrastructure as code is actually standing security standard they are running policy based Access Control they have for example a rule that say only um developers can create S3 buckets in AWS right so only they can deliver uh cloud formation or terraform
file that include creation of S3 buckets this policy decision do not require any kind of data the subject is on the request the action is clear create the uh resource is S3 bucket right so this is driven by policy but it's hard when we need to incorporate data to it another form of course based access control is course B course grin authorization is role based Access Control
this is the most common one is a Sy many people just call authorization world based Access Control world based access control is good it has very good experience because we can say this user has a role of admin this user has a role of admin and a moderator this user has a role of user and then we drive the permission by the roles of the users right
so we determine what kind of permissions user will get by their rules still it's very subject oriented if for example we want we want to have a level of granularity on the resources so for example we want to say only admins can access PDF files it's getting harder and harder because we are bringing more variables into the policy decision and that getting arbach complex and it's actually
why arba considered coar grain because we cannot have fine grain granularity on on the permission that we are getting this is an example very simple example in a Healthcare System we have Rick and Morty Rick and as Dental member and mobile agreement roles and it gives them some um permission in a very specific resources and we also have uh Morty that has paid users but what we
have here it's not enough in a world full of data in a world that we want to have fine grain permissions and this is where attribute based and relationship based access control get into the picture both two uh um models calculate also the resources in the way that we are getting decision what is relationship based access control so every entity in our application has some relation relationship
with something else right even if you look on relational databases easy to imagine but at the end even if you look an abstract API endpoint so API endpoint are belong to some form of same Authentication or belong to some form of same resources has some ID that you can connect with other IDs what if we can take this relationship assign one resource to one user and drive
the permission by it what if we can have a long long set of Access Control list that say Gabriel has this document so they allowed Gabriel has the other folder so they allow it is not enough right because it's only one relationship so we have like giant re relationship based access control and this is exactly the problem that Google found because if you think about Google Google
is one of the most multi-domain companies at the world they have Enterprise products they have Cloud products they have media product they have advertisement product tons of product all has one identity now just look for example something that I experience from the perspective of authorization let's say that I have my business Gmail I have a Google ads account where manage my ads and I also have a
YouTube channel how can Google Google determine that in my Google ads account I should have access to my private YouTube videos right the only way to do that is build like a giant graph of all the relationship between resources and users in Google and then Reebok can drive a so-called graph relationship or endless hierarchy or role derivation there are many names to this one role derivation is
the one that I mostly like and that's actually said if I have a role to one resource so let's say if I have an admin role on one folder in Google Drive then I get a derivation to all the folders and files that actually related to that and that's the way actually permissions work in Google because Google released a paper called Google Zanzibar something that became very
popular and drive lot of fine grain authorization implementation Google bar is actually describe how actually work and the main thing in Google Zar the first one is relationship toppos every entity in our system is related to someone right we are modeling all our system in a giant graph and each resource can belong to one or other entities second is RO derivation if I am assigning a user
to one resource in this graph I can also put the user in the graph then they are derived the same role to all the other entities in the graph after that we have of course this graph that determine and this Access Control list what a user can do instead of being access control of billions being access control that narrow to R assignment and the derivation is derived
by the graph and then we get a fine grain authorization because we can have a calculation of every resource in the details for what user is Cloud without explicitly assign them roles to these resources I hope it's clear reback for at the first point is something that sounds confused and even my diagram is even more confusing than that I'll try to go over it so we have
here the same Rick and Morty and what we want to get in this Healthcare application we want to allow user access to different user resources so for example I want to allow Rick to access to a subset of Morty resources now in arbach if you think about it I'll have to explicitly assign a caregiver role to Rick for every of Morty sorry I always confused between to
every each of the uh Morty plans right but in reuk the purple one that you see is an explicit assignment but the red is actually a derivation so if I am assigning run caregiver Ro then because they are related in the graph right the the um the dark brown um AR Rose if they are related I can derive also the red one the caregiver one rebok can
sound again complex at the beginning but after you use one of the implementation that actually exist many of them as open source will get soon to the specific implementation that I personally like you'll get very simple outof box fine grain authorization system another fine grain authorization model is so-called attribute based access control attribute based Access Control came with the assumption that every entity in our software has
attributes right even in the world everything has attribute the colors the place the where they locate what is the time now Etc what if we can get all these attributes and build condition sets based on them right I can assert one attribute so for example I can say if Gabriel equal equal if Gabriel r equal equal admin so return allow but what if I can create condition
sets on top of this assertion and then we can incorporate both users and resources as set instead of saying user Ro at one level of granularity I can create a user set with many assertion and maybe even nested assertion and assert them with the assertion that I'm doing the same with the attribute of the resources attribute based access control is actually very common in some uh time
sensitive system because in reack we need to create this graph right we need to create the relationship in attribute based access control everything can arrive from the context itself we can get the data in the context and the policy engine will just get a decision so attribute based access control is built for decentralized system it has some problems because we have to be very explicit with the
assertion what does that mean so in reuk because we have the graph we do not need explicit assertion of the conditions we can just have one condition equal to true and then the graph will derive the permission in attributes we need them to be explicitly assigned to the attributes themselves here is an example for a specific uh role in abak that we are allowing user only between
dates and of course the best thing if you can afford it is to combine arbach reback and abak together and balance between the experience because arbach of course gives the best experience I'm just assigning assign in role to user developer experience that it's a little harder with abach but easier in reback and also performance now that we understand I have a little demo to show you that
incorporate all the component but I see that I left only 15 minutes so I'll continue with the deck and if we'll have time for demo later we'll get to the demo the last is the confidence we want to get a confidence and if you remember programming languages solve confidence with domain specific declarative language authorization today also have domain specific declarative language we let's look even for example
on this one so this is a declarative language that declare policy rules you can see here two conditions as you can see this language is built of first we have the subject action and resource which we discussed is the best design pattern we can have for authorization we also incorporate conditions here this is a very simple condition like a resource we are checking what is the attributes
in this resource and there is also the aback condition attribute based condition and we do assertion right what if we have this kind of declarative language that allows us to declare the policies that we want to have in our application the good news there are too languages the first one that I'll talk about today is a language called Rigo and it's used by open policy agent open
policy agent is is a policy engine a very famous one in the market since 2015 I was involved in open policy agent from the first days I must say that in 2015 it wasn't that great because instead of that we just wrote oursel policy engine but a open policy agent today is a mature product that can help you a lot with doing policy decisions not only authorization
but we'll get to that soon the language that you you saw is something that called AWS cedar cedar is a language that released by AWS a year ago for scientific proof authorization decision if you have a very sensitive system and you want to make sure that the authorization happen very fast Cedar came with a scientific proof testing framework that you can test how long your decision will
take and last is an implementation of Google Zanzibar and we'll get to that soon with details called open fga so the first one what we are looking here is Rigo code is the open policy agent code one of the thing about open policy agent is it's multi-purpose it's not built for authorization in application or for authorized developers to deliver Cloud product it's built to get policy decision
and that make it a little sorry a little more complex than the other Alternatives I personally super like open policy agent because I know how to work with the language but for most of the people I would not recommend to start with open policy agent for authorization because the language has some learning curve that is not easy to most developers in the other end open policy agent
is the only thing that can give you actually what I call multi-domain analysis or multi-domain policy engine because open policy agent is so generic you can get decision for multiple types so for example here is just an example for use cases that you can do is policy open policy agent and product that you might know built on top of open policy agent API Gateway there are plugins
that's example con plugging every API Gateway has a open policy agent plugin also in the some feature flagging solution use open policy agent to get feature flag um decision in the infrastructure you can Implement open policy agent if you're around the kubernetes or the cloud native ecosystem you know that many of the infrastructure related to open policy agent also you can put it everywhere a product that
I like a use case that I like is called kcks kcks is a open source library that allow people actually to um check their infrastructure as code static files this is not authorization but it's still based on open policy agent so if you think that you'll need to implement a policy engines in your system of a policy agent is a great choice if not better go with
one of of the other options the first one I'm showing here is AWS Ceder Cedar is a language that built for attribute based Access Control why because they don't want to St to store centralized data if you remember we mentioned that in relationship based Access Control we need this centralized graph there is option to decentralize the graph but then we are losing the scientific proof because we
have latency when we are sharding the graph and in this attribute based Access Control in in aw C we can very easy get high level or fine grained attribute based access control um I personally love cedar because as you saw the language is very simple to use it's very intuitive it's just you you look at the code you understand what is it it's very oriented to authorization
yet it's hard to deal with relationship data and this is where we are getting to open fga this is the syntax of relationship in open fga what you can see here which is a by the way a great example of find grin authorization is the authorization model of GitHub right we have here all the resources of GitHub the relationship in GitHub for example a member a repo
admin in relation based Access Control we can maybe chain roles to each other to create more relationship in our software and when we deploy actually open fga with this kind of configuration and put all our data right we are syncing the user relationship into the open fga engine we can can very easy get relationship based decisions open fga as con because it support only relationship it has
very limited support in role based access control but it do not support any kind of attribute conditions and I found that many needs attribute condition as part of the authorization system um so open fga is alternative or the opposite of AWS cider and yeah open fga is the opposite to consider and open policy agent can do everything for you for example at permit we are using internally
in open policy agent to model policies in arbu aback and reback but for customer who want to write the code themselves we are recommending to start with either cedar or open fga to extend their policy with fga I think that was the most overwhelming uh part of this talk and sorry if I'm mistaken and all this stock overwhelming um but I think it's important to know that
there are tools out there that can help you if you want to check there are many many large companies that uh tell can tell you about what you can what they choose what the model they choose uh actually I I haven't any kind of Link here but if you just Google like authorization at Netflix you find an article how they do it with Opa if you Google
authorization in redit you can find an article how to do it with uh um open policy agent so you can also read the use cases how they solve that and now you can solve also fine grin authorization yourself I also want to talk about an open source product that I am one of the maintain maintainers of you heard about all this policy Technologies but now you have
a big step between them and implement it in your environment right you need to manage all the policy files you need to manage the data into the policy engine you need to make sure that it's all fit with the software development life cycle so the developers now not getting the hardest of writing many many policies I I will ask you if you're going there just please star
it on GitHub giving star to open source maintainer is help us to grow so open policy uh Administration layer or opal is actually an author endtoend authorization service that based on policy engine you can work with Opa you can work with AWS Cedar in it and that's actually help help you implement with one Docker file composed a whole authorization system again based on policy engine we are
going to support also open fga soon uh to today we are support only Opa and Cedar but H this is a great start if you want to get endtoend authorization service these are actually the specification we have in opal opal is built to support seamless so when you deploy opal you are configuring what is your git repository of your policies and opal automatically know how to synchronize
your git branches with your policy engine that run per Branch so for example you can deploy opal server and then tell them okay for production track this branch of policy and for staging this branch and for developer environment this branch and then at every step on the software development life cycle you can get only the relevant uh policy is for this step in the life cycle so
here I I left five minutes so I think it's better than go to the a question because I saw there are some um okay so the most popular question was what was your most challenging situation in authorization code development as a end user or as someone who developed authorization system presumably developed who one Who develops the systems yeah so one of the main problem is incorporate this
policies code systems and this is actually what led us to develop opal as an open source is the incorporation with the software development life cycle are there many anyone here already got to work with any policy engine like Opa or Cedar okay that's surprising sometime there are one or two very angry hands that I raised up one of the thing about incorporating new programming languages and new
technologies is how developers react right when developer get okay I think now authorization is not good we need a new language to create policies they say I don't want to learn a new language especially not the angly one but if we are giving them a nice developer experience we are giving them a more influen way we are influen the way that they are actually so the main
challenge is developer experience the solution is make sure it work in it incorporate so two solution the first one is make sure it's incorporate with they do not have to create too much effort just in the process of incorporating that the second solution for that is to make sure you minimize the touch point with other stakeholders so for example you should consider internal permission management uh portal
or use some of the permission Management Services out there instead of letting developers control permission themselves because then all the time product managers Etc will came to them hey change that change that so it's better to uh Outsource the part of the permission uh configuration okay and I think we might have time for this last one arac seems to be a mighty but isn't it a performance
killer having to Traverse the graph for subjects and resources for every single authorization query yeah that that's a great question every time that people get familiar with Zanzibar that's the first question they ask them themselves Google that created the paper luckily own the internet so they don't mind they can deploy a whole graph of all their users everywhere and it will cost them nothing for us if
we have for example multi- region application we still need to deploy this giant graph the solution that we found for that is do Shing on that graph we using eventual consist to manage uh different decentralized graphs and then what we are doing we have a very specific subset of the graph it's actually partial configurable what part of the graph you are putting in every region or every
part of the graph and then by eventual consistency mechanism you can make sure that if part of the graph is not exist you at least know that part of the graph can change the decision and then you can let the application it's a little complex but rebok is complex I'm allowing myself take the step forward but what you can do with eventual consistency and say you you
should know that there are some part of the graph that not exist here if the decision needed that part of the graph then go to the other and Shard it to the current one so that's the solution that we find with decentralized graph but this problem is valid one of the main problem of relationship based access control is uh getting older graph by the way Trav tring
is not the main problem traversing did not take a time in a good model graph traversing is the less problem the main problem is that you need to actually have a petabytes of D metadata but yeah I guess it s
