ACL design

DA only supports IMS for authentication, not Microsoft and Google like Helix Admin.
Authorization it is based on IMS Group IDs and User IDs.
Which user belongs to which group is done through IMS Admin Console.
There will be just two permissions read and write , where write contains read.

Permission Configuration:

Concretely, there will be a permission sheet (like an xcel sheet) where authorization rules can be defined.
There is the idea that maybe there is an org level permission sheet and a site level permission sheet that get concatenated.
The site level permission sheet might have need a special write permission on the file to be able to edit it, even if you have write on /*.

Example:

path	groups	actions
/*	Group A	write
/products/photoshop	Group B	write
/products/photoshop	Group A	read
/products/photoshop/newlaunch	Group A
/products/photoshop/newlaunch	Group B, User X	write

Conventions:

• /products/* -> Matches all decedents without self.
• /products/+* -> Matches all decedents plus self.
• /file -> Matches the File (.html)
• /folder/ -> Matches the folder itself.
• /products/ -> matches just the products folder So .html file and folder paths are specified the same way and apply depending on whether what we find is a file or a folder.

Permission Evaluation The way that the rules are evaluated is:

• For each request path, the user ID and each group the user is part of is individually evaluated
• Only the longest rule that matches the path is applied.
• The resulting permissions are unionised, resulting in the most permissive one winning.

Examples:

• Group A has write permission top level, so they can write into /test or /test/file or /test/folder/smth.json , etc.
• Group A has only read permissions in /products/photoshop , which means they cannot edit it
• A user that's only Group A cannot read or write into /products/photoshop/newlaunch
• A user that's in both Group A and B can read and write into /products/photoshop/newlaunch , because at least one of the groups has write