Skip to content

Using ACLs

Jump to bottom
David Bosschaert edited this page Dec 18, 2024 · 29 revisions

Note that this feature is currently under development and not yet released

Each folder and page in DA can have access control permissions. This allows an administrator to specify who can see pages and who can edit.

Declaring ACLs

ACLs are declared on the owner organisation level configuration in a sheet called permissions.

Screenshot 2024-12-18 at 11 43 47

Actions

Permissions are defined as actions on a per-path basis. Each path listed gives permissions to individual users or IMS groups. The following permissions can be given in the actions column:

  • read: the user can read resources on the path
  • write: the user can write resources on the path; write implies read permissions too
  • (nothing): the user does not have any permission on the path

Groups

Users/groups are specified in the groups column. This is a comma-separated list of user emails and/or IMS Orgs/IMS group tuples. The IMS IDs can also be used instead of the descriptive name or email address.

Path syntax

The following path syntax is supported:

  • /project/dir/document1 - matches this specific document (document1) and nothing else. In the above screenshot [email protected] is given write access to the /project2/newsite/docs/factsheet document
  • /project/dir/sheet1.json - matches this specific sheet (sheet1) and nothing else. In the above screenshot [email protected] is given write access to the /project2/newsite/docs/factsheet document
  • /project/dir/img1.jpeg - matches this specific image (img1.jpeg and nothing else. In the above screenshot [email protected] is given write access to the /project2/newsite/docs/factsheet document
  • /project/dir/subdir1 - matches this specific folder (subdir1) and nothing else
  • /project/dir/* - matches all documents and folders under /project/dir but does not match the dir folder itself. In the above screenshot '[email protected]` is given read access to all documents and folders under /project2/newsite
  • /project/dir/+* - matches all documents and folders under /project/dir including the dir folder itself. In the above screenshot users in the IMS group IMS Org A/IMS Group are given no access to /project2/newsite/notes and its subfolders and documents.

Note that the path syntax for both a folder and a document is identical. If it is necessary to distinguish between these - when there is a folder with the same name as a document, a document can also be addressed as /project/dir/document1.html

Process

To find a user's allowable actions the following process is used.

For each of the user's matching groups:

  • email
  • IMS user ID
  • IMS Org name/Ims Group name
  • IMS Org ID/Ims Group ID

The longest matching path for a requested resource is searched and the allowable actions are looked up. Once a matching path is found the searching stops for this group.

Then all actions found are merged into a set and returned.

As an example, let's assume that [email protected] is in IMS Org A/IMS Group and needs access to /project2/newsite/food/monday. The ACL lookup finds that IMS Org A/IMS Group has its longest path defined as /project2/newsite/+* with read permissions. The ACL lookup also finds that [email protected] has write permissions to /+* which is the longest matching path for the email address. The resulting action set for the requested resource is the combination of these: read and write.

Example

An an example let's walk through the above screenshot.

Lines:

  1. Both [email protected] and [email protected] have write permissions to the root of the MyOrg organisation. Having write permission also means they have read permission. This means that they can list all projects and they can have full access to any project not further specified in the ACL sheet. If we assume there was a /project3 then both have full write access to that.
  2. [email protected] has its permissions taken away for the /project1 project. As the .../+* syntax is used joe can also not list the contents of the /project1 folder.
  3. Any user in IMS Org A/IMS Group or in IMS Org B/IMS Group 2 has read access to /project2/newsite and it's subfolders and documents. Because the .../+* syntax is used these users also have rights to list the /project2/newsite folder itself. [email protected] and [email protected] already have write access to this folder and its subfolders. Even if they are in these IMS Org+Group the fact that they have write permission is not taken away as the write permission is granted on their email address.
  4. [email protected] is only given read access to subfolders and documents of /project2/newsite/docs. So this line takes away the write access for these paths. Note that [email protected] still has write permissions here.
  5. [email protected] is given write access to the /project2/newsite/docs/factsheet document, making this the only document in this folder (and subfolders) that this user has write access to.
  6. Users in IMS Org A/IMS Group do not have any permissions on the /project2/newsite/notes folder, subfolders and documents. So users in this group will not be able to list this folder or see any of its content. So this limits the permissions given to these users in line 4. Note that users in IMS Org B/IMS Group 2 still have read permission here and also users that are in both will still have read permission as they are evaluated per group and the union of the results is taken. Also note that [email protected] [email protected] still have write permission to this path and its subpaths.
Clone this wiki locally