Using ACLs - adobe/da-live GitHub Wiki
Note that this feature is currently under development and not yet released
Each folder and document in DA can have Access Control definitions. This allows an administrator to specify who can see documents and who can edit.
Declaring ACLs
ACLs are declared on the owning organisation level configuration in a sheet called permissions
. For example:
Actions
Permissions are defined as actions on a per-path basis. Each path listed gives allowable actions to individual users or IMS groups. They are specified in the actions
column:
read
: the user can read resources for this pathwrite
: the user can write resources for this path;write
impliesread
permissions too
Groups
Users/groups are specified in the groups
column. This is a comma-separated list of user emails/IDs and/or IMS Org/IMS group tuples. The IMS IDs can also be used instead of the IMS descriptive name or email address.
The following values are possible:
- email - e.g.
[email protected]
note that using this form means that the user can be in any organisation, including their personal one - IMS user ID - something like
[email protected]
- IMS Org name/IMS Group name - e.g.
My Org/My Group 1
- IMS Org ID/IMS Group ID - e.g.
FEDCBA987654321/1234567
It's also possible to combine IMS names and IDs, for example using an IMS Org ID with an IMS Group Name: FEDCBA987654321/My Group 1
.
Path syntax
The following syntax is supported for paths:
/project/dir/document1
- matches this specific document (document1
). 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
)/project/dir/img1.jpeg
- matches this specific image (img1.jpeg
). Also applies to PDFs, videos, audio files, etc./project/dir/subdir1
or/project/dir/subdir1/
- matches this specific folder (subdir1
)/project/dir/*
- matches all documents and folders under/project/dir
but does not match thedir
folder itself. In the above screenshot[email protected]
is given read access to all documents and folders under/project2/newsite/docs
/project/dir/+*
or/project/dir/ + *
- matches all documents and folders under/project/dir
including thedir
folder itself. This effectively is the same as the previous item with the containing folder added. In the above screenshot users in the IMS groupIMS Org A/IMS Group
are given no access to/project2/newsite/notes
and its subfolders and documents.CONFIG
- this special value governs the permissions for the owning organisation configuration.
Note that there isn't any distinction between a folder and a document in how paths are evaluated. 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 with its .html
suffix: /project/dir/document1.html
The order of the rows in the sheet is not important. At runtime the paths are sorted by length and for each group the longest matching path is used.
Where 'documents' are mentioned above this means text documents, sheets and other resources such as PDFs, videos and audio files.
Process
To find a user's allowable actions the following process is used.
For each of the user's matching groups, 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 union of these: read
and write
.
Example
As an example let's walk through the above screenshot.
Lines:
- Both
[email protected]
and[email protected]
havewrite
permissions to the root of theMyOrg
organisation. Havingwrite
permission also means they haveread
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 fullwrite
access to that. [email protected]
has its permissions taken away for the/project1
project. So Joe can't access any documents or folders under/project1
. As the.../+*
syntax is used Joe can also not list the contents of the/project1
folder itself.- Any user in
IMS Org A/IMS Group
or inIMS Org B/IMS Group 2
hasread
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 havewrite
access to this folder and its subfolders. Even if they are in these IMS Org/Group the fact that they havewrite
permission is not taken away as the write permission is granted on their email address. [email protected]
is only givenread
access to subfolders and documents of/project2/newsite/docs
. So this line takes away thewrite
access from line 2 for these paths. Note that[email protected]
still haswrite
permission here.[email protected]
is givenwrite
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.- 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 documents or subfolders. This reduces the permissions given to these users in line 4. Note that users inIMS Org B/IMS Group 2
still haveread
permission here and also users that are in both will still haveread
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 from line 2.