what is the issue with having authorisation being done by service owning that resource . In the approach discussed in video , every service need to send entity and ownership information to auth service(this can be done by change detection). I don't understand the need of it. I think auth service should authenticate user and pass on responsibility of authorisation to service owning that resource or entity. In approach discussed in video if there is a new type of entity two teams will need to coordinate to handle authorisation .
How do we implement permissions to create a specific resource with this schema? e,g, with this model, we can derive if the user has write permission on listing id#10. But how can we derive the user has create permission on listing resource
But there are going to multiple reference for the listing:$x @ RESERVATION # ___? Right? Might have to go through multiple enitites to get if the user:123 has any reservation reference or not ? Am I thinking right? Anyone?
Can someone tell me - if cache invalidation does not happen instantly and if a unauthorized user (who previously had access) tries to access a resource, we grant them access and this could be serious. How do we make sure that the lag in cache invalidation does not affect authorization (or access to specific resources) ? Can someone think of any specific approaches to overcome this ?
@Arpit, When you don't find entry for the user in the cache, how would you know whether (a) it was not in the cache but present in DB, or, (b) the entry is not in the DB because the user is not authorized? would you always hit the DB in that case, and if so, would the cache be useful only for positive scenarios?
The chances of this happening is highly unlikely. My thought would be to use a write through cache along with a read through.( cons :- cache is a single point of failure(distributed cache would be helpful) , first hit will always be a cache miss, extra added latency of writing to cache and writing to Database(2 phase commit) pros :- strong consistency b/w db and cache). Here acc to the diagram it looks like a cache aside pattern. (I could be wrong)
That is not the primary usecase of the service. System is optimised for quick lookup of A access to B. So even if finding all resources that A has access to takes time that is okay.
I still don't think that the rule engine is good enough for complex cases. Ex, what would be the query for this - Allow READ for property 1 if a user referred 10 people between 1 nov and 7 nov to visit that property page?
But you have assumed here that part of the entity won't be a nested object. For example, what if a comment is a nested object and I need granular control of authorization over the sub-part of the part of entity ?
such a beautiful design with simple building blocks ! Also congratulations Arpit .. well deserved :)
what is the issue with having authorisation being done by service owning that resource . In the approach discussed in video , every service need to send entity and ownership information to auth service(this can be done by change detection). I don't understand the need of it. I think auth service should authenticate user and pass on responsibility of authorisation to service owning that resource or entity. In approach discussed in video if there is a new type of entity two teams will need to coordinate to handle authorisation .
How do we implement permissions to create a specific resource with this schema? e,g, with this model, we can derive if the user has write permission on listing id#10. But how can we derive the user has create permission on listing resource
Being an embedded software engineer....great content to understand a distributed system and its database design concepts
Zanzibar paper a must read for this to understand along with that there are permissions defining languages which visualise it and store it in dbs
But there are going to multiple reference for the listing:$x @ RESERVATION # ___? Right? Might have to go through multiple enitites to get if the user:123 has any reservation reference or not ?
Am I thinking right? Anyone?
One of a kind, always great content!
Can someone tell me - if cache invalidation does not happen instantly and if a unauthorized user (who previously had access) tries to access a resource, we grant them access and this could be serious. How do we make sure that the lag in cache invalidation does not affect authorization (or access to specific resources) ? Can someone think of any specific approaches to overcome this ?
This is called as "enemy problem" " and google uses Zookie cookie to tackle this. Read a cookie cookie in google zanzibar papaer.
@Arpit, When you don't find entry for the user in the cache, how would you know whether (a) it was not in the cache but present in DB, or, (b) the entry is not in the DB because the user is not authorized? would you always hit the DB in that case, and if so, would the cache be useful only for positive scenarios?
Arpit, what if user reads from the cache before kafka finishes cache invalidation , which is possible. Isn't it a flaw ?
The chances of this happening is highly unlikely. My thought would be to use a write through cache along with a read through.( cons :- cache is a single point of failure(distributed cache would be helpful) , first hit will always be a cache miss, extra added latency of writing to cache and writing to Database(2 phase commit) pros :- strong consistency b/w db and cache). Here acc to the diagram it looks like a cache aside pattern. (I could be wrong)
how would you implement this in a multi tenant setup?
Great Content
Great explanation. Does this system work for fetching all resources that a user have permission to?
That is not the primary usecase of the service. System is optimised for quick lookup of A access to B. So even if finding all resources that A has access to takes time that is okay.
By this way m they have micro level action handling capability
great stuff!
Has Airbnb also open sourced its Himeji codebase? Or do we have to write from scratch? @Arpit
Amazing!
Another great video.
I still don't think that the rule engine is good enough for complex cases. Ex, what would be the query for this - Allow READ for property 1 if a user referred 10 people between 1 nov and 7 nov to visit that property page?
This is extremely contextual and has to be part of business logic or a highly attuned data model.
@@AsliEngineering Got it. So basically, Himeji is most suitable for basic and less contextual logic, right?
Amazing
confused, why is read union of read and write?
is it like an OR condition
@@Su_Has yes it's like an OR condition. User with write priviledges also has the priviledge to write it
Pass..... Bit complicated for me 😐
Too much costly design. just to implement Authorization 😐
Needed for a company that operates such a massive scale. There are far too many entities and actions craving ACL.
But you have assumed here that part of the entity won't be a nested object.
For example, what if a comment is a nested object and I need granular control of authorization over the sub-part of the part of entity ?
We may represent a part of the entity using the dot notation to capture the path.
example: entityType:entityID:part.sub-part1.sub-part2