User access rights and permissions within Preservica are mapped to user roles, which are assigned and managed either in an external system, such as Microsoft Active Directory and OpenLDAP, or using the built in Preservica User Management module (see Section 4.9 for more details).

When a user logs in to the system, Preservica will authenticate the user against the user credentials store, and obtain the user’s details (name, e-mail address, Organisational Unit) as well as the roles that have been assigned to that user.

System security can be applied by two independent mechanisms. Firstly, access to system functionality is controlled using a set of pre-configured Preservica roles (see Section 4.2.1), and secondly, access to content is controlled using permissions associated with either the pre-configured Preservica roles or by the addition of custom roles (see Section 4.2.2).

Any additional roles that are added to the system only govern access to content and metadata and do not affect a user’s ability to access system functions.

Preservica provides a default configuration of content security using the pre-configured functional roles and two access control tags (“open” and “closed”).

Access control by high level function

Preservica is divided into “functional areas” that broadly correspond to the functional entities of the OAIS reference model (and the links in the page header). A set of fixed functional roles exist that provide access to those areas:

• ROLE_SDB_ACCESS_USER - This role allows a user to browse and retrieve files and DIPs.
• ROLE_SDB_SUBMITTER_USER - The role only allows access to page which lets the user download the upload wizard installer. A user with this role will have no access to any other features of Preservica.
• ROLE_SDB_ADMIN_USER - This role grants a user access to the administration functionalities of the Preservica application, and full access to the Job Queue and Explorer applications. Caution should be exercised in granting this role. An unwitting or malicious user with admin privileges could cause serious damage to the archive infrastructure. This role is not available to you on our cloud hosted systems.
• ROLE_SDB_ANONYMOUS_USER - This role is used by the Universal Access application to control the content and metadata shown to unauthenticated users. It doesn’t have any functional permissions in the application
• ROLE_SDB_DATA_MANAGEMENT_USER - This role grants a user access to the data management workflow system in Preservica, which allows a user to re-index, re-characterise, appraise, delete, and generally manage the archive’s content.
• ROLE_SDB_INGEST_USER - This role grants a user access to the ingest workflows system in Preservica. This allows them to submit data to the archive.
• ROLE_SDB_MANAGER_USER - This grants a user access to the archive administration functionalities of the Preservica application, and full access to the Job Queue and Explorer applications. Caution should be exercised in granting this role. An unwitting or malicious user with manager privileges could cause serious damage to the archive’s data.
• ROLE_SDB_REGISTRY_ADMIN_USER - A user with this role can edit existing entries in the Registry and create new ones. This role is not available in Preservica Professional or Enterprise editions..
• ROLE_SDB_TRANSFORM_USER - This grants a user access to the transformation workflows system in Preservica. This allows them to create and schedule format migrations, creating new accessions both for archival and for testing purposes. These fixed roles come pre-configured within Preservica. In the case of an on-site Preservica installation they must be added to any external authentication system. Further, these are the only roles in Preservica that can be used to control access to these functional areas, any custom roles can only define content security. This means that if a user is required to be able to run ingest workflows they must be granted one of the ROLE_SDB_ADMIN_USER, ROLE_SDB_MANAGER_USER or ROLE_SDB_INGEST_USER roles. Similarly, to be able to run ingest and preservation workflows a user must have either one of ROLE_SDB_ADMIN_USER or ROLE_SDB_MANAGER_USER, or both ROLE_SDB_INGEST_USER and ROLE_SDB_TRANSFORM_USER. Within the user management system the required user accounts should be identified (or created) and the appropriate functional role (Security Groups in Active Directory) or roles assigned to allow the users to access Preservica functions.

Content Security

Preservica supports the concept of security classification of content, e.g. Open, Restricted, Secret, Top Secret etc., via the XIP metadata field “SecurityDescriptor”. If a user does not have access to the appropriate security classification they cannot see the content and/or metadata and it will not be returned by search activities etc. Preservica has a flexible approach to implementing a security classification scheme. The system is initially configured with two security classification levels, ‘open’ (visible to all users) and ‘closed’ (not visible to any users). Preservica treats all security classifications as independent and does not hold a hierarchy of classification levels. The default configuration for the ‘open’ setting is shown in Figure 4.7. For more details on the permissions see Section 4.2.3 below

Additional security tags can be created as required: press the Add Tag button and enter the name of the new security tag in the dialog box that appears. The new security tag(s) can be used to apply different levels of access to archival content. Created tags will be added to the drop-down list of security tags and by selecting the security tag, the appropriate permissions for the different roles can be set in the table. Additional content security roles can be configured as required: press the Add Role button and enter the name of the new security role in the dialog box that appears. Any new security roles will have no functional permissions. The new role(s) will be added to the list of roles and the appropriate permissions for the different security tags can be set. Roles added to Preservica must be prefixed with the characters “ROLE_” (omitting the double quotes). Before these roles can be assigned to an individual user, they must be added to the user management system where the “ROLE_” prefix should not be included.

Security Model

Preservica defines seven distinct permissions, which can be set on a “per tag, per role” basis. For a given tag, these permissions are defined below:

• Read Metadata - Users with roles that are granted this permission are able to see the metadata associated with archived entities. In particular, this means that they can browse Explorer for these entities and see them in API results. Users without Read Metadata permission won’t see that an entity exists at all.
• Update Metadata - Users with roles that are granted this permission are able to change the metadata associated with archived entities. Creating new entities, links etc are considered to be metadata changes and so this permission also allows users to perform these operations. All changes are audited.
• Delete Entity - Users with roles that are granted this permission are able to run Delete workflows on archived entities, removing them completely from the archive.
• Read Content - Users with roles that are granted this permission are able to see the digital content, i.e. the digital files, of archived entities. In particular, they are able to download individual files (through Explorer or APIs), or include those files in DIPs created through export workflows.
• Insert Content - Users with roles that are granted this permission are able to store content during ingest. This permission is also required to save new content generated by the system during migration.
• Read Permission - Users with roles that are granted this permission are able to read the security tag for archived entities. This can be displayed in Preservica Explorer through the entity context menu
• Change Permission - Users with roles that are granted this permission are able to change the security tag for archived entities. This can be set in Preservica Explorer through the entity context menu (see the system user guide gSUG] for more details).

The check boxes on the ‘sdb/security.html’ page allow for live updating of these permissions for each security tag (i.e. the permissions take effect immediately).

Whether an individual user can carry out a specific action depends on the combination of their functional role(s) and content security permissions. That is, the user needs to have an appropriate functional role (see ???) in order to access the required functional area within Preservica, but in addition the user needs to have the appropriate content permission(s) for the archival entities affected by the action.

Content Security and Ingest

When content is ingested the security classification of the content (as defined by the “SecurityTag” field in the XIP metadata) is checked. The ingesting user1 must have the Insert Content permission on the security descriptor assigned to every Information Object and Content Object in the ingest package, and must have Update Metadata permission on the security descriptor assigned to every Structural Object (folder) in the package, and also on the folder into which the package is being ingested. Even if the user performing the ingest has access to the Preservica Explorer application, they will not be able to see any information relating to the ingested content unless they have the correct security permissions (i.e. Read Metadata permission)

User access rights and permissions within Preservica are mapped to user roles, which are assigned and managed either in an external system, such as Microsoft Active Directory and OpenLDAP, or using the built in Preservica User Management module (see Section 4.9 for more details).

When a user logs in to the system, Preservica will authenticate the user against the user credentials store, and obtain the user’s details (name, e-mail address, Organisational Unit) as well as the roles that have been assigned to that user.

System security can be applied by two independent mechanisms. Firstly, access to system functionality is controlled using a set of pre-configured Preservica roles (see Section 4.2.1), and secondly, access to content is controlled using permissions associated with either the pre-configured Preservica roles or by the addition of custom roles (see Section 4.2.2).

Any additional roles that are added to the system only govern access to content and metadata and do not affect a user’s ability to access system functions.

Preservica provides a default configuration of content security using the pre-configured functional roles and two access control tags (“open” and “closed”).

Access control by high level function

Preservica is divided into “functional areas” that broadly correspond to the functional entities of the OAIS reference model (and the links in the page header). A set of fixed functional roles exist that provide access to those areas:

• ROLE_SDB_ACCESS_USER - This role allows a user to browse and retrieve files and DIPs.
• ROLE_SDB_SUBMITTER_USER - The role only allows access to page which lets the user download the upload wizard installer. A user with this role will have no access to any other features of Preservica.
• ROLE_SDB_ADMIN_USER - This role grants a user access to the administration functionalities of the Preservica application, and full access to the Job Queue and Explorer applications. Caution should be exercised in granting this role. An unwitting or malicious user with admin privileges could cause serious damage to the archive infrastructure. This role is not available to you on our cloud hosted systems.
• ROLE_SDB_ANONYMOUS_USER - This role is used by the Universal Access application to control the content and metadata shown to unauthenticated users. It doesn’t have any functional permissions in the application
• ROLE_SDB_DATA_MANAGEMENT_USER - This role grants a user access to the data management workflow system in Preservica, which allows a user to re-index, re-characterise, appraise, delete, and generally manage the archive’s content.
• ROLE_SDB_INGEST_USER - This role grants a user access to the ingest workflows system in Preservica. This allows them to submit data to the archive.
• ROLE_SDB_MANAGER_USER - This grants a user access to the archive administration functionalities of the Preservica application, and full access to the Job Queue and Explorer applications. Caution should be exercised in granting this role. An unwitting or malicious user with manager privileges could cause serious damage to the archive’s data.
• ROLE_SDB_REGISTRY_ADMIN_USER - A user with this role can edit existing entries in the Registry and create new ones. This role is not available in Preservica Professional or Enterprise editions.
• ROLE_SDB_TRANSFORM_USER - This grants a user access to the transformation workflows system in Preservica. This allows them to create and schedule format migrations, creating new accessions both for archival and for testing purposes. These fixed roles come pre-configured within Preservica. In the case of an on-site Preservica installation they must be added to any external authentication system. Further, these are the only roles in Preservica that can be used to control access to these functional areas, any custom roles can only define content security. This means that if a user is required to be able to run ingest workflows they must be granted one of the ROLE_SDB_ADMIN_USER, ROLE_SDB_MANAGER_USER or ROLE_SDB_INGEST_USER roles. Similarly, to be able to run ingest and preservation workflows a user must have either one of ROLE_SDB_ADMIN_USER or ROLE_SDB_MANAGER_USER, or both ROLE_SDB_INGEST_USER and ROLE_SDB_TRANSFORM_USER. Within the user management system the required user accounts should be identified (or created) and the appropriate functional role (Security Groups in Active Directory) or roles assigned to allow the users to access Preservica functions.

Content Security

Preservica supports the concept of security classification of content, e.g. Open, Restricted, Secret, Top Secret etc., via the XIP metadata field “SecurityDescriptor”. If a user does not have access to the appropriate security classification they cannot see the content and/or metadata and it will not be returned by search activities etc. Preservica has a flexible approach to implementing a security classification scheme. The system is initially configured with two security classification levels, ‘open’ (visible to all users) and ‘closed’ (not visible to any users). Preservica treats all security classifications as independent and does not hold a hierarchy of classification levels. The default configuration for the ‘open’ setting is shown in Figure 4.7. For more details on the permissions see Section 4.2.3 below

Additional security tags can be created as required: press the Add Tag button and enter the name of the new security tag in the dialog box that appears. The new security tag(s) can be used to apply different levels of access to archival content. Created tags will be added to the drop-down list of security tags and by selecting the security tag, the appropriate permissions for the different roles can be set in the table. Additional content security roles can be configured as required: press the Add Role button and enter the name of the new security role in the dialog box that appears. Any new security roles will have no functional permissions. The new role(s) will be added to the list of roles and the appropriate permissions for the different security tags can be set. Roles added to Preservica must be prefixed with the characters “ROLE_” (omitting the double quotes). Before these roles can be assigned to an individual user, they must be added to the user management system where the “ROLE_” prefix should not be included.

Security Model

Preservica defines seven distinct permissions, which can be set on a “per tag, per role” basis. For a given tag, these permissions are defined below:

• Read Metadata - Users with roles that are granted this permission are able to see the metadata associated with archived entities. In particular, this means that they can browse Explorer for these entities and see them in API results. Users without Read Metadata permission won’t see that an entity exists at all.
• Update Metadata - Users with roles that are granted this permission are able to change the metadata associated with archived entities. Creating new entities, links etc are considered to be metadata changes and so this permission also allows users to perform these operations. All changes are audited.
• Delete Entity - Users with roles that are granted this permission are able to run Delete workflows on archived entities, removing them completely from the archive.
• Read Content - Users with roles that are granted this permission are able to see the digital content, i.e. the digital files, of archived entities. In particular, they are able to download individual files (through Explorer or APIs), or include those files in DIPs created through export workflows.
• Insert Content - Users with roles that are granted this permission are able to store content during ingest. This permission is also required to save new content generated by the system during migration.
• Read Permission - Users with roles that are granted this permission are able to read the security tag for archived entities. This can be displayed in Preservica Explorer through the entity context menu
• Change Permission - Users with roles that are granted this permission are able to change the security tag for archived entities. This can be set in Preservica Explorer through the entity context menu (see the system user guide SUG] for more details).

The check boxes on the ‘sdb/security.html’ page allow for live updating of these permissions for each security tag (i.e. the permissions take effect immediately).

Whether an individual user can carry out a specific action depends on the combination of their functional role(s) and content security permissions. That is, the user needs to have an appropriate functional role (see ???) in order to access the required functional area within Preservica, but in addition the user needs to have the appropriate content permission(s) for the archival entities affected by the action.

Content Security and Ingest

When content is ingested the security classification of the content (as defined by the “SecurityTag” field in the XIP metadata) is checked. The ingesting user1 must have the Insert Content permission on the security descriptor assigned to every Information Object and Content Object in the ingest package, and must have Update Metadata permission on the security descriptor assigned to every Structural Object (folder) in the package, and also on the folder into which the package is being ingested. Even if the user performing the ingest has access to the Preservica Explorer application, they will not be able to see any information relating to the ingested content unless they have the correct security permissions (i.e. Read Metadata permission)