You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm currently working on implementing authentication in atomic-server and atomic-data-browser. I know how to implement the current concepts, but I can already see some serious inefficiencies.
If we only use hierarchies for rights, we get many unneccessary database calls. For example, let's assume a user wants access to some publicly available, deeply nested (lots of parents) resource. Before the server knows it is allowed to return it, it might need to check all parents to find read rights, only (in this case) to find some read rights for the public at the top.
Ideally, the server could in one go know which rights are applied to this resource, without checking all parents.
But... We don't want to explicitly set all rights for every resource. Especially when rights get complicated, this could mean a lot of duplicated data, and resources with a lot of boilerplate.
So... Let's create resources to describe rules and rights.
GrantSet Data model
A set of permissions
A collection of rights
Examples:
The publicRead GrantSet - a resource (hosted by AtomicData.dev) that describes that all individuals have read access to this resource.
The thingsMyColleagesCan grantset - describes a list of colleages, and their rights
Counter-thought
But how does this help? If we'd introduce groups, why would we need to use these grantsets? The groups could also solve the performance issue mentioned in the intro.
And doesn't this make things more complicated? Can't we solve this with hierarchies?
The text was updated successfully, but these errors were encountered:
joepio
changed the title
Resources that describe rights: GrantSets
ACL - Resources that describe rights: GrantSets
Nov 13, 2021
Relates to authentication #55 and authorzation / hierarchies #18 . Maybe also to roles and groups #68
See technical implementation discussion
Goals
User stories
Inspiration
Performance considerations
I'm currently working on implementing authentication in atomic-server and atomic-data-browser. I know how to implement the current concepts, but I can already see some serious inefficiencies.
If we only use hierarchies for rights, we get many unneccessary database calls. For example, let's assume a user wants access to some publicly available, deeply nested (lots of parents) resource. Before the server knows it is allowed to return it, it might need to check all parents to find read rights, only (in this case) to find some read rights for the public at the top.
Ideally, the server could in one go know which rights are applied to this resource, without checking all parents.
But... We don't want to explicitly set all rights for every resource. Especially when rights get complicated, this could mean a lot of duplicated data, and resources with a lot of boilerplate.
So... Let's create resources to describe rules and rights.
GrantSet Data model
Examples:
publicRead
GrantSet - a resource (hosted by AtomicData.dev) that describes that all individuals have read access to this resource.myFriendsRead
Grantset - describes a list of friends, gives them the right to read the thing Groups or Role-based authorization #68thingsMyColleagesCan
grantset - describes a list of colleages, and their rightsCounter-thought
But how does this help? If we'd introduce groups, why would we need to use these grantsets? The groups could also solve the performance issue mentioned in the intro.
And doesn't this make things more complicated? Can't we solve this with hierarchies?
The text was updated successfully, but these errors were encountered: