Security Modelling Guide

This article describes ShareDo's various security capabilities and some common scenarios. It is designed to guide the planning and configuration of security protocols and is supported by more detailed help articles on specific configuration items.

This article is comprised of the following sections describing the overall capabilities offered:

Managing Authorisation Globally: ShareDo provides a large number of fine-grained global permissions, the grant of which controls a user's ability to fulfil a specific function.
Managing Authorisation for a Work Item: the same permission model is then extended to individual work items (Cases, tasks, etc), enabling access and actions on those work items to be controlled.
Limiting Access to people, users and teams: ShareDo maintains global lists of people, organisations and the like. You can configure ShareDo to expose only a subset of this information for specific use cases.
Application Level Security: describes how you can configure your authentication mechanisms together with securely allowing external applications access to ShareDo’s APIs.

Managing Authorisation Globally

ShareDo controls the actions that a user can or can’t perform at a system level via global permissions.

Global permissions are designed to either enable or disable pieces of functionality within the application. They are described at a reasonably granular level and there are in excess of 400 permissions available.

While global permissions can be granted individually to users, this is not a very maintainable strategy. Hence, they are grouped into permission sets. Permission sets are then assigned to security teams, of which users are members.

Global permissions are typically used to manage scenarios such as:

Granting different levels of permissions between Administrators, Case Handlers and Managers.
Providing a cut-down set of permissions for external users, e.g. Consumers or B2B Clients.

Global Permissions

ShareDo provides 400+ fine-grained permissions. These are available in the administration portal.

While there are many permissions available, these are categorised as follows:

CATEGORY	DESCRIPTION	EXAMPLE PERMISSION
Admin	Provides a set of permissions that are required to access the admin portal and its functional for managing Features, Document templates, Security and ODS entities	“Admin Access” – permission grants access to the admin portal
Audit	Provides a set of permissions enabling users to view audit information including the fine grained audit and the business chronology	“Audit – View Chronology” – enables the chronology to be viewed
Collaboration	Enables control of collaboration functionality including comments and analysis notes	“Comments – Private Comments” – enables users to view and change privacy of comments.
Documents	Provides fine grained control over document management capabilities including ability to file and manipulate documents	“Documents – Preview Documents” – enables users to preview documents
Finance	Enables control of finance related features including Fees, Delivery Costs and Budgets	“Finance – Fees – Actuals – Edit” enables uses to add actual fees
Linked Cases	Controls user’s ability to add references between different work items	“Linked Cases - can view” enables users to view links
ODS	Controls what generic operations a user can perform against People, Teams, Users etc	“ODS - Search – People” can search for people
Reports	Report permissions are generated automatically based on the reports that are present in the solution	“Reports - View - Payment Summary Report” use can view the payment report
Scorecards	Permissions related to managing scorecards	“Risk Assessment – Read” read scorecards
Search	Restricts access to different types of searches	“Search – Advanced” enables access to advanced search functionality
Security	Controls various security access privileges including the granting of tokens	“Security Barriers – View” enables users to view security barriers
ShareDo	These permissions are predominantly generated automatically based on your work type config. For example, if you create a new case type then the “Create” permission will be created automatically	“ShareDo - Create – Absence” user can create an Absence task
Task	Controls access to task related features such as delegation	“Tasks – Delegate” user can delegate tasks
Teams	Enables abilities to create and manage teams	ODS – Team – Create user can create teams
Time	Permissions related to time capture and management	“Time – record for others” user can record time on behalf of other people
Users	Enables management of users	“User – Manage All” a system admin permissions for managing all users

Permission Sets & Teams

Although it is possible to assign permissions to users or teams individually, this process would be very laborious. Instead, permissions are typically grouped into permission sets.

New Permissions are constantly being released. To facilitate adoption, they are automatically updated to the system permission sets. You then have a choice to make: You can either use the existing permission sets and amend them with your own changes, and permissions will be automatically added to them, or you can create clones of them.

These permission sets can then be assigned to teams, and members of those teams will be given the relevant global permissions.

By convention, we recommend only assigning permission sets to a special type of team, “Access Control Lists”. Your team types and their settings are specified under /modeller/team-types.

Managing Authorisation For A Work Item

The previous section described the ability to lock down functionality globally via permissions and permission sets. However, this doesn’t address the requirement to lock down a subset of functionality for a given work item, such as a Case, Matter, Task, or Key Date. This level of access control is managed via work item-level permissions, their assignment to roles, and security barriers.

Work Item permissions determine whether a user can read, update, or progress a work item's milestones.

Work Item permissions are assigned to a user or a team based on their assignment to roles on the work item. It is the roles themselves that are granted permissions.

For example, a user named Bob is assigned the Matter Owner role on a case. The Matter Owner role is configured to have read and update permissions, so Bob can see and update Matters on which he is the Matter Owner.

Work Item permissions are typically used to manage scenarios such as:

Providing clients access to a sub-set of Matters.
Providing clients access to a sub-set of Tasks.
Ensuring that Matters cannot be updated once closed.

Work Item Permissions

For a given role on a given work type, you can assign what work item permissions are granted. The following permissions are available.

PERMISSION	DESCRIPTION
Read	Users with this permission are able to see this work item. If this permission is not present then a user will not be able to open this work item nor will they be able to search for it or report on it.
Update	Users with this permission are able to update information on this work item. If this permission is not present then a user cannot update information on a work type.
Delete	Users with this permission are able to delete work items.
Audit	Users with this permission are able to access work item level audit functionality such as the fine grained audit and the chronology.
Participant assign	Users with this permission are able to assign participants to this work item. For example they can assign a case owner or task recipient.
Participant Read	Users with this permission are able to see participants related to this work item.
Progress Milestone	Users with this permission are able to progress the milestone or phase of a work item. For example they can progress a real estate case into the completion phase.

It's important to understand that work item permissions and global permissions operate together. A user must possess both the global permission and the relevant work item permission to access specific functionality.

Assigning Permissions To Roles

By default, when you create a new work type, no one can access it to perform operations on it. It is completely secure and cannot be accessed in any way.

To provide access to it, you then need to go through the process of:

Granting the global create permission for this work type to a permission set and, hence, a team for it to be initially created.
Assigning permissions to specific roles.

Security Team Roles

It is common in ShareDo implementations to have a common set of roles designed explicitly to provide permissions to users. Indeed, the out-of-the-box configuration ships with such roles, including:

ROLE	DESCRIPTION
Reader	Users assigned to this role typically only have read access to the work item.
Contributor	Users assigned to this role are typically granted access to perform the majority of operations on a work item.
Client Access	Users assigned to this role are provided a limited set of permissions in-line with your client access requirements.

It’s important to recognize that these roles are not inherently "special." They are set up similarly to any other roles, complete with respective permissions. Therefore, if you wish to create your own authorisation scheme, you are welcome to do so.

Where a role is designed for security only, the convention is to flag this role as a security team role.

Roles flagged as security team roles are displayed in the Security Team section of the Manage Participants blade for a matter.

Access can be restricted through the global permission labelled "ODS - Edit Participants - Security Team."

Restricting Role Permissions By Phase

The previous section describes how a user or team assigned to a role will be given permissions based on that role. This model can be further extended to cater for scenarios such as the following:

Restrict the case owner’s ability to update a Case once it is closed.
Disable a task owner’s ability to update the task details when it is in approval.

ShareDo facilitates requirements like these by allowing you to vary the participant role permissions by phase.

Preventing Accidental Assignment of Users or Teams to Roles

When you assign a user or team to a role with permissions on a work item, they will be given privileges on that work item.

For example, if you assign Bob the role of “Case Owner” on a matter and the “Case Owner” role has read and update permissions, then Bob will be able to see and update that Matter.

While this is expected behaviour, it is also open to mistakes. For example, if there are two Bobs in the system and the user accidentally assigns the wrong Bob to the Matter, there could be a potential data leakage incident.

Whilst it is impossible to mitigate all instances of incorrect usage in the system, ShareDo does provide a useful feature that acts as a fail-safe in these scenarios:

Security Barriers

Security barriers allow you to configure your organisation's security policies. Once in place, they effectively lock down security assignments and remove most opportunities for human error.

Examples of where security barriers are used include the creation of policies concerning:

Only certain internal teams or users can see this matter.
Only certain external users can see this matter.
Only internal people can be a member of this team.
Only certain people from the parent matter can be the payee on a payment or offer.

Security barriers are configured:

Globally or for a work type instance and its descendants.
For given role(s), including those of its descendants.
Specifying either the superset of users, as defined by teams, roles, individual users or parent roles that can play a specific role on a work item, or the inverse, those that cannot play a role.

Since these rules are hierarchical, we can also specify them at child levels. For example, I can define a rule at the contract level that applies to its child matters and then further specialise this at the matter level.

A common use case for security barriers is to combine them with roles that are assigned via the hierarchy. For example, you will often create a security barrier on a Statement of Work role to stop accidental assignment of people to a client matters.

For more information, see the article Security Barriers.

Extending The Read Permission Into The Reporting Database

When a “Read” permission is assigned to a Work Item, this information is also sent to the reporting database. Hence, when a report is run, it will inspect a user’s permission and return only those work items to which they have been granted access.

Hence, it is often the case that different users will see different results when running the same report.

Assigning Roles Based On The Work Type Hierarchy

While it is perfectly feasible to assign users or teams to every work item individually (either manually or via workflows), this would be a very laborious process and subject to error.

Instead, the typical system configuration is for work items to inherit user or team participant assignments via the work type hierarchy.

If you consider a typical work type hierarchy and the common security requirements:

All cases are created under a client (or product line) Statement of Work This provides a grouping for client cases.
The assignment of people or teams on the Statement of Work then provides the basis for all matters and defines the initial set of people who can access a specific matter.
All tasks created under a matter then also inherit the security permissions of the Matter.

ShareDo facilitates requirements such as these by configuring participant synchronisation‍.

To configure requirements such as the above, we would do the following.

Configure the default users against the Statement of Work.
Configure a synchronisation rule to copy down the relevant roles to the child cases.
And then configure further Synchronisation rules to copy down the roles to tasks.

Restricting Access to Specific Functionality via the Portal or Blade Editors

The sections above describe the high-level permissions that can be assigned when accessing a work item; however, you will often need more fine-grained control over the specific functionality displayed to your users.

ShareDo enables you to control access to the following.

Pages and Widgets – through the portal editor, you can configure specific permissions required to access functionality.
Blade Editor – specifying permissions around which widgets are shown for blade (preview) views.

Restricting Access to Pages and Widgets

Within the portal modeller, at either a workbench or work type level, you can specify permissions using business rules for the following.

Pages – only users with the specified permissions can see the page in their navigation scheme.
Widgets – the same security can also be applied to individual widgets on a page so that the overall display will be restricted.

A common configuration pattern is that rather than reusing portal definitions across different types of users and adding permission checks to individual pages or widgets, a different persona will be created, and a completely separate portal definition will be used instead.

Restricting Access To Aspects

You can configure permissions for blade widgets in a similar manner to portal pages and widgets, controlling which users have read or update permissions.

Limiting Access to People, Users and Teams

ShareDo maintains a master list of users, people, teams, and organisations, which is collectively known as the ODS (or operational data store). The ODS is viewable in its entirety within the application's admin area.

When assigning a role to a work item, the user then searches the ODS list for the relevant participant.

By maintaining a single list of entities, we promote a " 360-degree” view of a person's interaction with our clients. While providing a full view of participants is highly desirable from the perspective of relating records, ShareDo also enables the restriction of these searches to prevent data leakage issues.

ODS Security is typically used to manage scenarios such as:

Preventing external users from querying the list of users or people.
Limiting the list of search results to a subset of organisations or people.

Restricting ODS Searches

When a user queries the ODS database, they get a list of pertinent entities. Since clients typically manage hundreds of users and thousands of individuals or organizations within the system, ShareDo allows searches to be narrowed down in multiple ways, including the following options.

Disabling the ability to search – the easiest and most secure method of restricting access to the ODS for external users is simply to turn off the ability to search for entities and instead require external users to add these if necessary.
Limiting results to a subset of entities - if you want your users to still be able to search the master list of ODS entities but wish to restrict the result sets returned, you can configure the ODS query that is used.
Globally limiting results by using Information Walls - the most secure method for restricting access to ODS Entities is to implement Information Walls.

Disabling Search

Global permissions, including ODS - Search - People and ODS - Search - Users, control the ability to search the ODS store. If these permissions are removed from the relevant permission set, the associated users can no longer view a list of these entities.

To facilitate certain user journeys, such as supporting clients entering a counterparty's details, you can:

Enable the ability to create ODS entries – users will not be presented with a search form but will only be able to add ODS details. Administration functionality exists to enable the deduplication of these ODS entities and maintain data quality.
Alternatively, you can restrict access to the ODS Database in its entirety and instead provide a custom form for entering these details. Once entered, these details can then be managed via a workflow.

Limiting Results via ODS Party Types

Rather than enabling users to search a full list of ODS entities, you can restrict the available entities via Party Types. Party types describe a sub-division of a list of ODS entities and are often configured for Clients, Experts or Suppliers.

Individual roles can then be configured to use only certain Party Types, restricting the list of ODS Entities returned in a search.

Sourcing Rules

For a given participant role you are also able to configure the sourcing rules.

Sourcing rules enable the configurator to determine what list of ODS Entities are returned when assigning a given participant role. The configurator can choose from the following:

Enabling a full search of the ODS Entity list subject to any party type restrictions.
Only allowing a search against ODS Entities that are on related work items and roles. This configuration setting can be used to fulfil use cases such as the following:
1. Only allowing emails to be sent to Participants who are present on a case.
2. Only allowing tasks to be allocated to a set of Participants who are defined on the parent statement of work.

ODS Information Walls

While the ODS security measures described above can be used to restrict access to ODS entities for most use cases, they require some configuration and are not “on” by default.

ODS Information Walls (found in Admin > Security > ODS Security Walls) are designed to provide a single place where ShareDo configurators can configure the following.

Information Walls – An information wall defines a unique group of ODS Entities together with the security teams that can access them.
The Default Wall – when an ODS Entity is created, it is placed in the default wall. As members of the default wall will have access to most, if not all, ODS Entities, access to this should be controlled carefully.
The work types from which you will inherit walls - this is typically the statement of work but could, in theory, be any work type in the system.

Once activated, when an ODS Entity is created, it will be assigned an Information Wall through the Work Type Tree alongside the Default Wall. Users can then only query ODS Entities for the walls to which they have access.

Furthermore, subject to global permissions, Admin users are provided with a tool to manage the membership of these walls, along with the capability to bulk assign or remove walls from specific entities.

Application Level Security

At an application level, ShareDo’s security is based on standard protocols such as OAuth and Open ID together with HTTPS.

ShareDo then tracks, audits and correlates user access tokens across all layers of its architecture.

Identity Providers

Oauth Access Delegation

OAuth is an open standard for access delegation. Internet users commonly use it to grant websites or applications access to their information on other websites without giving them passwords. ShareDo uses OAuth extensively to grant secure access to both user-centric and application-to-application clients. All of ShareDo’s APIs require tokens to be able to access them.

Examples of common client applications include:

ShareDo Outlook and Word Add-ins.
External workflow engines.
External client applications that require access to ShareDo APIs.

Where ShareDo relies on external services, these can be added as linked services.

Encryption

ShareDo supports the encryption of sensitive data at rest, such as when we store credentials to access external resources. Data in transit is encrypted through HTTPS. When operating in the ShareDo SaaS environment, the virtual machines in Azure are deployed with disk encryption, and all backups taken and stored are encrypted.

Auditing

ShareDo maintains two ‘audit’ streams. The first is a forensic one as contemplated by the question—e.g. each and every touch-point, whether this be data changes, task updates, etc. This record contains the date & time, user and changes made.

The second is a case chronology. This is a user-friendly, graphically rich history of key case steps designed to help an end-user (internal or external) understand the ‘case-related events’ that have occurred on the case.

Additionally, the user context is captured in each log message, providing an even finer-grained audit. Actions taken by users are recorded in these audit logs, which are also available in reporting.