Access Control defines whether a single User or a user in a Group (legacy) or Team has the permission to view, change, or delete an entity such as an Asset, Collection, Storage, or Metadata View. These user and group permissions are compiled on an entity in an Access Control List (ACL).
Owners can always change who has access, and if a user has the correct roles or Access Control, they can also change the Access Control for other Users, Groups (legacy) or Teams.
Access control is defined using the Access Control Lists for entities such as Assets, Metadata Views, Storage, Transcoders, Export Locations, and Collections. It is usually changed where you manage those entities, such as the Admin page for Storage, Transcoders, Export Locations, or the Asset/Collection page for the Assets/Collections.
Access Control Lists can also be grouped together into ACL Templates, which can then be used to provide a set of permissions to incoming Assets from a storage, or entities that a User in a Group (legacy) or Team creates.
Roles
These are the roles that are needed:
- Owner
Administration of Access Control.
ACL Templates
ACL Templates work together with Access Control Lists so that Access can be easily defined and applied to Assets and other entities being created by users in a user group or Assets and Collections that are created from files coming in from Storages such as Cloud Storage or the iconik Storage Gateway.
The Permission Template is used when an Asset or Collection is created. Retroactively editing or removing a Permission Template doesn’t change the Permission or ACL of any Asset, Collection, or other entity that had its ACLs set by the Template.
Inherited Access Control.
Up to 1,000 collections in your system can have access control lists that are automatically applied to content added to that collection. We call these Inherited ACLs - because the Assets or Sub-Collections inherit the ACLs from the “parent” collection.
The Assets or Sub-Collections can also have their own ACLs to define further access and who is allowed to view them.
Iconik’s Access Control Lists always define who has access and what level of access and never remove access, so this design should be taken into consideration when building up a collection tree of access to collections and sub-collections. You should start with the minimal amount of access needed on the parent collections to perform the needed work—you can always add more permissions further down the tree.
Negative ACLs
Iconik doesn’t implement negative ACLs - ACLs that disallow access, as this design can quickly become hard to manage with thousands of collections and millions of assets, particularly when serving up search results to users and having to take into account which assets and collections a particular user is allowed to view.