Skip to content

ACL - Resources that describe rights: GrantSets  #73

Open
@joepio

Description

@joepio

Relates to authentication #55 and authorzation / hierarchies #18 . Maybe also to roles and groups #68

See technical implementation discussion

Goals

  • fine grained / enterprise access control possibilities
  • easier management of rights we don't have to change individual resources, we can edit a grant, even if it spans across parents / hierarchies
  • Improved performance by making it not required to check every parent recursively

User stories

  • Have a table of my colleagues where I can set boxes for thing that they have access to
  • See which resources John can view / delete
  • Have paid tiers in something like patreon / onlyfans
  • Add a new colleage

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

  • 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 myFriendsRead Grantset - describes a list of friends, gives them the right to read the thing Groups or Role-based authorization #68
  • 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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions