One of the key objectives of a security model on a document management platform is to restrict and control access to documents stored in the repository.

Selecting a security model

Complexity in selecting a good security model lies in two conflicting requirements behind it:

• The security model needs to be sufficiently granular to allow flexibility in allowing access to relevant documents to various users and roles across wide variety of Organisations and use cases.
• Security model needs to be simple so it can be established and managed efficiently, allowing for continuous changes. 

This is an extremely complex and contentious topic and its discussion exceeds the scope of this document. 

For PIQNIC  we have chosen the model based on Access Policies based on the following:

Access policies

Access policies are metadata based rules designed to carve out a set of documents from the repository having the same security profile. 

Because of unrestricted flexibility of the metadata model (on our platform document classes and the users can have practically an unlimited number of metadata fields associated with them), Access policies can be finely tuned to apply to the correct set of documents that delivers the necessary granularity of the model. 

Single access policy can only apply to one document class, but there could be an unlimited number of access policies defined for any document class. 

Access policies are assigned to roles (user groups) – single access policy can be assigned to multiple roles and each role can have many access policies assigned. 

Once in place and assigned to a role, an access policy silently restricts the scope of every search members of the role run. Efficiency of this approach lies in the fact that document security is not managed individually through file or folder access lists but by setting a single access policy affecting a large number of documents within its scope. 

Access policies are cumulative. Where we have more than one access policy defined against a document class, and these access policies are assigned to one or several roles that the user is a member of, they will be appended to each other using OR clause. In case of a View access policy, the resulting access policy is then AND-ed to each search users run against that document class.  

What we have described is the behaviour of one of three possible types of access policies that we can define on the platform. 

The other two types are Modify access policies and Create access policies which control whether a user can modify repository documents or create new ones. 

Modify and create access policies are built in the same way and follow the same logic as View access policies – using document and user metadata we build rules that determine whether the user can modify or create a document. 

For each document that is to be modified or created, we check its metadata against all access policies for that document class and assigned to roles the user belongs to. We need at least one to evaluate true for the action to be allowed. 

Single access policy can have more than one type assigned to it. In these cases, metadata based rules  contained in the policy are shared and applied to each assigned policy type. 

Net effect is the same as if we had two or three individual single type policies with identical metadata rules.

Searches

Searches are the principal tools for users to find documents and files in the system repository. Each search is defined as a collection of user prompts and/or pre-defined search values. 

Searches are created using the Search Builder administrative tool and assigned to a role. Users/members of the role can use all searches assigned to it.  Each search can query only one document class but we can have any number of searches defined on the document class. 

When users execute a search, all View access policies for the queried document class inherited through the role memberships are appended to the search and matching results are returned to the user. The layout of the search result list is also configured in the Search Builder. 

In PIQNIC, we can run non-native searches using different search providers (this release supports Google searches). Results returned by Google search are effectively URLs and can be saved as personal bookmarks or as loosely managed documents to the PIQNIC repository using one of the Save Profiles. 

Security restrictions do not apply to non-native searches but apply to URLs saved to PIQNIC and returned by a PIQNIC search. 

Users can take any administrator defined search, populate its fields with commonly used search criteria and save it as a Favorite Search available only to them.

Save Profiles

Save Profiles are principal tools for users to save content to the system repository. 

Similar to searches, they are built in the Administrative tool and assigned to a role. User/members of a role, that a Save Profile is assigned to, can use it to save documents. Each Save Profile is a collection of prompts, pre-set values and constraints controlling how users assign metadata to documents they are saving. 

Each Save Profile can save documents to a selected document class but there are no restrictions on the number of Save Profiles associated with a document class. 

Before the document is committed to the system, its metadata is checked against all Create policies associated with the relevant document class that is assigned to the user, saving the document (through their role memberships). At least one Create policy needs to evaluate true for the document to be saved. 

Users can take any administrator defined Save Profile, populate its fields with commonly used search criteria, and save it as a Favourite Profile available only to themselves. 

Save Profiles are exposed to users as Drag and Drop zones through which they can ingest their files (or URLs). 

Delegated access

Security model of the Collaboration platform is completely different due to the nature of the collaboration requirements. It can be best described as delegated access. 

When a task is created, the task owner uses their security profile to pick and choose the relevant files (from within and outside the repository) for the collaboration session (task). 

Users invited to the task have unrestricted access to these files for the duration of the collaboration session. 

It is important to note that user activity within the task is captured on the Task wall. The task owner also controls how task users contribute to the task by selecting Save Profiles they can use to attach files to the task (and to the repository).