Access control for items, libraries, collections¶
Items, libraries and collections have access control lists that determine what operations a user can perform. The entries in the list either corresponds to a specific user or to an entire group.
Vidispine will use the access controls on the item, library or collection to determine if a user has access to perform a specific operation or not.
All entities will have a OWNER access control that identifies the user that created the entity, and that grants full access to it.
<AccessControlListDocument xmlns="http://xml.vidispine.com/schema/vidispine"> <access id="VX-21"> <loc>http://vs.example.com:8080/API/collection/VX-16/access/VX-21</loc> <recursive>true</recursive> <permission>OWNER</permission> <user>admin</user> </access> </AccessControlListDocument>
Here the admin user has created a collection, and is thus the owner with full
access. Access controls from collections, and libraries, are inherited to the
entities in them. The
recursive element can be used to control if the
access control should apply to the child items or not.
Manage access controls using the access control resource on the entity in question. For example, to grant access to Users, but only allow them access to certain shapes:
POST /collection/VX-16/access Content-Type: application/xml <AccessControlDocument xmlns="http://xml.vidispine.com/schema/vidispine"> <permission>READ</permission> <group>users</group> </AccessControlDocument>
POST /collection/VX-16/access Content-Type: application/xml <AccessControlDocument xmlns="http://xml.vidispine.com/schema/vidispine"> <permission>NONE</permission> <group>users</group> <operation> <shape> <tag>original</tag> </shape> </operation> </AccessControlDocument>
To view the access controls that apply for an item, including any access controls inherited from parent collections or libraries, see Viewing applied access controls.
The higher levels grants the permissions of the lower levels.
- Grants no permissions whatsoever.
- Grants permission to read.
- Grants permission to write.
- The highest level that grants permissions to perform operations such as item deletion.
- A specific case of ALL that is given by the system. This level cannot be added or removed.
The access control lists are sorted in order to determine which entry that applies to a given operation. The rule of thumb here is that if there’s a matching access control entry set on the item then that applies otherwise the item’s ancestor collections and libraries are traversed. Then the collection or library that grants the lowest access will apply. If no matching access control entry can be found, access will be denied.
Furthermore an access control entry that is more specific take precedence over an entry that is less specific. If two entries are determined equally specific then the entry that grants the highest access applies. An example of this is that an entry that restricts access for an items entire metadata is considered less specific than one that only restricts access for a certain field in the metadata.
The above can be illustrated by the priority list below:
- Controls with a high explicit priority take precedence over controls with lower explicit priority.
- Controls directly on the item take precedence over controls on ancestor collections and libraries.
- Controls that describe specific users take precedence over controls that describe groups.
- Controls that are more specific take precedence over controls that are less specific.
- If directly applied to an item:
- Controls that grant more access take precedence over controls that give less access.
- If applied to an ancestor collection or library:
- Controls that grant less access take precedence over controls that give more access.
An explicit priority can be assigned by setting the
priority element in the
AccessControlDocument to the desired level. The default is 0. Note that
only superusers can create access controls with an explicit priority as users
would otherwise be able to gain access to entities that they shouldn’t have.
The user that created an access control entry is also tracked. This is the grantor. It is also so that an entry is only valid if the grantor still has access to the entity. This means that access can be revoked by removing the original entry that granted access.
For example, let’s assume that user A is the owner and grants READ access to user B, that in turn grants READ access to user C, as shown in the figure. Users A, B and C now all have read access. If the access control granting READ access to user B then the user C will no longer have access.
There are different types of operations that can be restricted using access control lists. Parameters are optional and makes the access control entry more specific. If no operation is specified then the entry will be considered generic and apply to the entire item.
|Parameters||type||The type of the URI to restrict.|
<AccessControlDocument xmlns="http://xml.vidispine.com/schema/vidispine"> <permission>READ</permission> <user>testuser</user> <operation> <uri> <type>lowres</type> </uri> </operation> </AccessControlDocument>
|Parameters||tag||Restrict access to shapes with this tag.|
New in version 4.1.
<AccessControlDocument xmlns="http://xml.vidispine.com/schema/vidispine"> <permission>NONE</permission> <user>testuser</user> <operation> <shape> <tag>lowres</tag> </shape> </operation> </AccessControlDocument>
|Parameters||field||The name of the field to restrict.|
Removal of fields are currently not restricted
Currently fields can be removed without checking the specific access control entry.
<AccessControlDocument xmlns="http://xml.vidispine.com/schema/vidispine"> <permission>READ</permission> <user>testuser</user> <operation> <metadata> <field>title</field> </metadata> </operation> </AccessControlDocument>