Dynamic Actions and Possession Groups

[KrishnaPG]

Own and Any are equivalent to "user" and "world" in the unix ABAC, missing the "group".

Currently ownership verification is left out as responsibility of the application, which works fine for static ownership.

But context-based dynamic ownerships require the ability to create new possession levels programatically.

For example, a resource (say MP3 file) purchased by one user need to be allowed update access to immediate family members (so that his family members can add meta data), "play" permission to friends, allow "share" permission for both. Another user may want to allow all permissions to family and friends same. In all cases, the seller should have the permission to "update" the file (say, improved version auto-upgraded).

Now this "family members" group and "friends" group memberships is not static and dynamically determined from the resource owner (who purchased it). And the access permission preferences for both groups are not same for each resource or each user. These groups cannot be implemented as Role since membership varies based on context. Not possible to hardcode the ownership verification since the access permission preferences vary for each user, and new groups may be created on the fly with new permissions (and may further change over time).

This kind of access requires the ability to define Permission Groups and Actions dynamically. For example, CRUD may not be enough and developer should be able to define more (such as "share", "like", "email", "print", "copy", "backup", yada yada). Own and Any are not enough (too wide blanket), developers should be able to create dynamic groups and be allowed to specify permissions for each group.

Determining the group membership could be left to the developer, while the access permissions for those groups could be tracked by this library automatically.

[anodynos]

I'm not sure about the possession groups (own & any), as this is a big discussion of where these should actually be implemented (or better providing hooks so the APP developer can implement).

I think they belong to the implementation on your server or API or expressJS or NestJS middleware & decoratoros etc, and not in this library which deals with the Role definitions and assertions just fine.

BUT the action keywords feature will be amazing - I think too CRUD actions are very limiting :-( we need user-defined ones like list, share, play, like, follow etc)

[anodynos]

There's an (intermediate) solution to your problems https://github.com/anodynos/accesscontrol-re :-)