Customise the Security Model

By default, Sintelix comes with a Security Model to allow access to projects, collections and networks to be projected.

However, Administrators may need to customise the Security Model to suit the specific security protocols or standards of their organisation.

The Customised Security Mode is define in the file security-model.xml.

The model uses claims-based data security (also referred to as Attribute-based Access Control, or ABAC), where each user has attributes (‘claims’) and each piece of data has attributes (‘security metadata’). The logic that matches claims to security metadata is configurable and can be very simple (such as users and groups) or complex (such as multiple secrecy levels).

Claims-based security is configured in three parts:

• Each user has security claims
• Each project, collection and network has security metadata
• Rules are used to match security metadata with claims and define whether a particular user can access data

These parts correspond to the first three elements in the security-model.xml file, each of which is described below.

This element defines user security privilege property fields and is represented by the <claims-schema> XML tag.

In Sintelix’s security model, each user automatically has a claim ‘sintelix-access’ (values ‘admin’, ‘user’ or both) and claim ‘user-name’. Additionally, this security model defines a third claim called ‘group’, defined as a set of arbitrary strings. As a result, one user can belong to many groups.

<claims-schema>
    <property class="string" name="group" label="Group" min-occurs="0" max-occurs="0" />
    <!-- implied property sintelix-access -->
    <!-- implied property user-name -->
</claims-schema>

This element defines security access metadata property fields and is represented by the <security-metadata-schema> XML tag.

In Sintelix’s security model, every data item (collection, network and document) is defined with two properties: ‘group’ and ‘access’, each an arbitrary set of strings.

<security-metadata-schema> 
    <property class="string" name="users" label="Users" merge-type="INTERSECTION" min-occurs="0" max-occurs="0" />
    <property class="string" name="groups" label="Groups" merge-type="INTERSECTION" min-occurs="0" max-occurs="0" />
</security-metadata-schema>

This element defines security access rules and is represented by the <access-rule> XML tag.

In Sintelix’s default security model the access rule specifies that a user will be able to access data if any of the following conditions are met:

1. The user’s name matches any of the data’s property ‘users’ values. That is, one can add a user name to a collection’s ‘users’ list to grant them access.
2. The user is an administrator. That is, all administrators see all data. If this is undesirable, remove the rule.
3. The user belongs to at least one group that matches any of the data’s property ‘groups’ values. That is, one can assign users to a group, then assign data to the same group, and therefore grant them access.

<access-rule class="satisfy-any">
    <rule class="match-any"> <!-- require only 1 value from security-metadata property to be in claim values -->
        <claim>user-name</claim>
        <security-metadata>users</security-metadata>
    </rule>
    <!-- this rule gives Sintelix administrators full access -->
    <rule class="match-literal">
        <literal>admin</literal>
        <claim>sintelix-access</claim>
    </rule>
    <rule class="match-any">
        <security-metadata>groups</security-metadata>
        <claim>group</claim>
    </rule>
</access-rule>

This element defines default security access metadata that is applied to new projects. It is represented by the <default-security-metadata> XML tag.

This element is not in Sintelix’s default security model so new projects are accessible to everyone by default.

The example below secures new projects by default by copying the user name to the ‘users’ property and copying any groups the user is in to the ‘groups’ property. The first rule is necessary to ensure that a user has access to the project they created. The second rule immediately shares the project with members of the same group.

<!-- uncomment to make each new project default to only the user who created it -->
<!-- 
<default-security-metadata>
    <rule class="inherit-claim">
        <claim>user-name</claim>
        <security-metadata>users</security-metadata>
    </rule>
</default-security-metadata>
-->

This element defines the availability of additional security options and is represented by the <security-options> XML tag.

In Sintelix’s security model the two options below change the behaviour of Sintelix.

• <show-inaccessible> allows any user to see (but not open) all projects, collections and networks regardless of their security. Since Sintelix cannot have two projects, collections or networks with exactly the same name, this prevents surprises when a project/collection/network cannot be created because the name is in use. However, it exposes the existence of a project/collection/network to users who do not have access to open it.
• <per-document-security> allows each document to be uploaded with its own security metadata, in addition to the security of the project and collection itself.

<security-options>
    <show-inaccessible>true</show-inaccessible>
    <per-document-security>false</per-document-security>
</security-options>