Guide and Configuration of Security in WorkPoint 365

1. Introduction

2. WorkPoint Structural Hierarchy

3. Security Settings

   3.1. Business Module Entity

       3.1.1. Manual Security

       3.1.2. Inherit from current business module

       3.1.3. Inherit from parent business module

       3.1.4. Use security rules

   3.2. Business Module Entity Site

       3.2.1. Manual Security

       3.2.2. Inherit from current business entity

       3.2.3. Use security settings

   3.3. Adding Security Rules

       3.3.1. Active

       3.3.2. Type

           3.3.2.1. Static

           3.3.2.2. Dynamic

           3.3.2.3. Inherit

       3.3.3. Scope

           3.3.3.1. Entity

           3.3.3.2. Wizard

           3.3.3.3. SharePoint Group

           3.3.3.4. Office 365 Group

           3.3.3.5. Sharing

               3.3.3.5.1. Static

               3.3.3.5.2. Dynamic

               3.3.3.5.3. Sharing Capability Type

               3.3.3.5.4. Default Sharing Link Type

               3.3.3.5.5. Default Sharing Permission Type

               3.3.3.5.6. Sharing Type

           3.3.3.6. Site

           3.3.3.7. List

           3.3.3.8. Documents/items

           3.3.3.9. Email Manager Journal

   3.4. Activation Conditions for Security Rules

       3.4.1. Always

       3.4.2. Simple

       3.4.3. Advanced

4. Security Replication

   4.1. Types of Security Replication

5. List of Terms

6. Best practices

WorkPoint 365's security system has long been a robust tool for controlling permissions with features like security rules. While dynamic rules based on entities' metadata have been effective, they sometimes resulted in an undesirable number of security inheritance breaks.

With WorkPoint 365, comprehensive permission control is possible through rules and policies, ensuring that end-users need not concern themselves with the intricacies of permissions. Instead, permissions are automatically assigned based on user roles, streamlining access management. For instance, roles like project manager or team member dictate permissions, simplifying the process.  

WorkPoint also enforces governance over permissions, automatically rectifying unintentional changes. It's important to note that WorkPoint works within Microsoft's defined limits and boundaries. Security replication ensures compliance, and while WorkPoint simplifies control, it's essential to grasp the impact of your configuration on your solution.

WorkPoint Security works by defining security rules and activation conditions. Security rules consist of a security type, a security scope, and a permission level.

Security types work by declaring who the security rule should affect. Three types of security types exist:

• Static (the Active Directory user(s) or group(s) which the rule affects must be explicitly declared)
• Dynamic (the Active Directory user(s) or group(s) which the rule affects can be declared in a meta data field on an entity. That meta data field is then used for the security rule)
• Inherit (the specified scope inherits it's permissions from it's parent level. This type only additionally requires a scope, and not a permission level)

Security scopes define where the security rule applies, like a specific entity, site, or list.

The permission level specifies the access level granted to users or groups based on the rule.

For example, a static rule explicitly designates a person or group with Contribute permissions. In contrast, a dynamic rule links "Project Manager" to "Full Control" permissions, automatically assigning access. Some rules merely inherit permissions from a parent level.

Additionally, activation conditions determine when each security rule applies to individual items, enhancing fine-tuned access control.

In the following the configuration of WorkPoint security settings are explained in detail.

WorkPoint works with SharePoint and their components are ordered in a structural hierarchy. All documents, items, and folders are nested inside either a list or a library. These lists and libraries are located on a site, which is located in a site collection. Site collections are located on a Tenant, which is the top level of the structural hierarchy.

The hierarchy is illustrated in the image below:

The lowest level, where folders, items, documents, etc. reside is where SharePoint ends, and WorkPoint begins. In SharePoint, there is no level connected to e.g. an item. With WorkPoint, however, a SharePoint item can be linked with another site. A Business Module in WorkPoint terms is actually a SharePoint list of items, pointing to other sites. A Projects Business Module is in WorkPoint a SharePoint list, which items points to individual project sites from where project managers and teams can work on their individual projects. This relationship is shown in the image below:

Each item in the module list is what we refer to as an Entity.

The security permissions for each business module can be accessed from the WorkPoint 365 Administration Dashboard. Follow these steps:

1. Navigate to the WorkPoint 365 Administration.
2. Click the header for the business module for which you wish to manage security settings.
3. Click “Security Settings” from the list.

From here the user can edit the security settings for the given business module. An overview of the security settings dashboard is shown in the image below:

The individual sub-topics of the security settings dashboard are described in the following sections.

These options define which permissions should apply to the business module entity.

Each of the options are explained in the following sections.

Choosing Manual Security, WorkPoint will make no changes in addition the SharePoint security permissions. When this is selected users within the WorkPoint system or other systems will be responsible for setting the right permissions in WorkPoint.

Choosing this option, all entities in the list inherits their security permissions from the list settings.

Incremental security replication must be activated and configured to run at a given interval, if you choose to inherit from current business module. This is a feature that has to be set up by a WorkPoint representative. This feature should only be activated strictly when necessary due to performance reasons. It is usually only relevant if the entity is inheriting rules from its parent, and you want to apply security rules on the entity itself and replicate them to the site.

Choosing this option, all entities inherit their security permissions from their parent (e.g. a project can inherit its permissions from an associated company).

Permissions for entities are based on rules with entity scope.

These options define how permissions should be applied to the business module entity site.

Each of the options are explained in the following.

Choosing Manual Security, WorkPoint will make no changes in addition the SharePoint security settings. When this is selected the user or other systems will be responsible for configuring the right permissions in WorkPoint.

All entity sites inherit their permissions from their associated entities.

Incremental security replication must be activated and configured to run with a given interval, if you choose to inherit from the current business module entity.

In incremental mode, the system only applied any changes made since last replication.

Full mode maintains permissions for all entities in WorkPoint 365.

Permissions to all entity sites are based on security rules with Site scope.

The ‘Allow unique permissions on lists with no rules’ option pertains to the handling of list permissions on sites within the WorkPoint security system. By default, all lists on a site inherit permissions from the entity site. However, lists that are covered by at least one security rule are exceptions to this default behavior. When the ‘Allow unique permissions on lists with no rules’ option is enabled, WorkPoint will not inherit permissions from the entity site to underlying lists not covered by any security rules, making it possible for these lists to have unique permissions.

Security rules can be added by clicking the “Add security rule” button in the “Security rules” section.

This option turns the specific rule on or off. Only active rules will be applied.

This option defines the type of security rule. Available types are Static, Dynamic, and Inherit.

If this option is chosen, the security rule will apply to specific predefined users or groups, which can be selected by writing the initial, e-mail or name of the people and/or groups and selecting them from the people picker that shows up.

1. Type is set to “Static”.
2. Initials of a user is typed into the “Users and groups”-field.
3. A user with the initials can be chosen from the picker.

Note that if “Static” is chosen, the field that specifies the personnel that this rule applies to is named “Users and groups”.

Using this option, the security rule will apply to specific meta data fields from the entity. You can, e.g. define this rule for the Project Manager for a project. In that way, should the project manager change, you would only need to change the project manager of the project, and the security rule will automatically recognize the new project manager, and grant him/her access.

1. Type is set to “Dynamic”
2. Field name is set to “Project Manager” but could be set to e.g. “Project Assistant”, “Project Team”, or other groups or people. Also fields from parent modules are available, as shown in the following image:

If “Inherit” is chosen, the rule is based on SharePoint permission inheritance. Items will inherit their permissions from their parent in the structural hierarchy of the solution, as described in the image in section 2 in this document. This means that, if set, documents/items will inherit permissions from their list/libraries, lists/libraries will inherit permissions from their sites, etc.

With “Inherit” chosen, the administrator needs only choose the scope of the security rule, and eventually which specific list (if chosen), limitation field, and limitation value if “Documents/items” is chosen. See to section 3.3.3.8 for more information about limitation field and limitation value.

A case when this is useful is if a project has a confidental-field. If a project is confidential and only the project manager therefore can see inside it, but that confidentiality changes to be open to anyone, security rules can then be inherited again, so that anyone can now see inside the project. This makes the solution much more dynamic.

Scope selects which scope the security rule should target. There are several scopes to choose from, and some new scopes have been added in latest version of WorkPoint.

The business module entity list item. For this scope, the personnel for which the rule applies as well as the permission level must be set. Available permission levels by default are;

• Full control: Has full control.
• Design: Can view, add, update, delete, approve, and customize.
• Edit: Can add, edit, and delete lists. Can view, add update, and delete list items and documents.
• Contribute: Can view, add, update, and delete list items and documents.
• Read: Can view pages and list items and download documents.
• View Only: Can view pages, list items, and documents. Document types with server-side file handlers can be viewed in the browser but not downloaded.

If you add custom permission levels these will also be available and supported by WorkPoint

Access to a wizard. Restrictions have been put on Project Master Data such as Stages, so that these data cannot directly be changed and are now read-only. Changes can, however, still be made through a Wizard, which can have specialized security rules applied to them. Choosing “Wizard” in this field makes it possible to control which people have access to specific Wizards. For this scope, the personnel for which the rule applies as well as the specific Wizard must be set. For Wizards you can choose only those which contain an “Edit Entity” or “Change stage” step.

A useful case for this scope is when all project master data is read-only, but you want a project manager to be able to make changes to these data. Changes can be made through a wizard, which has its accessibility restricted by a security rule that grants access only to project managers. In effect, no one can make changes to project master data, unless they are in a project manager position.

Membership of a SharePoint group. SharePoint uses groups to manage the process that grants users access to various content on a site. SharePoint groups map to a set of permissions, which relates to which actions users can take, and which content the user can access. SharePoint users typically fall into one of the three default groups; Site Owners, Site Members, and Site Visitors. Custom groups can, however, be created.

One of the great benefits of using group-based security is automation. If security and permissions are based on groups, when members of the group change, the security system automatically recognizes the changes and grants or revokes permissions to members, based on their membership status of the group. This means that no other configuration needs to be done when a member leaves the group or joins the group. This is much more efficient and dynamic than having to grant or limit access for each individual user.

For this scope, the field from which to get users and groups from, and the specific target group must be set.

A useful case for this scope is if you only want members of a specific SharePoint group (e.g. Owners or Members) to be able to do a certain action. You could, e.g. restrict access to a certain document unless the person is a member of the SharePoint Owner group.

The associated Office 365 Group for the business module entity. Office 365 Groups is a way to centralize or group members for multiple Microsoft products in a single place. When creating an Office 365 group it is stored in the tenants Active Directory, also referred to as Azure Active Directory.

The benefits of using group-based security of this type is the same as described in section 3.3.3.3.

It is important to note that you cannot add AD- or SharePoint groups - only isolated users.

For this scope, the field from which to get users and groups from, and the specific target group must be set.

The sharing permissions for the business module entity site collection. If chosen, the administrator can input domains to either allow or block sharing to. This is useful for either restricting certain domains that items should under no circumstances be shared with, or for sharing items with only certain domains.

Specifying the domains to either share to, or prevent sharing to, depends on the type of the security rule.

For the static type, the domains can be individually typed into the text field provided, using the format domain.com. Multiple domains can be typed in by separating them with a carriage return. A maximum of 1,000 domains can be typed in. Note that Wildcards are not supported for domain types. This means that you cannot use the format “*.workpoint.dk”. Below is an example of domains entered.

For the dynamic type, domains can be retrieved from an entity field, which can be specified in the drop-down menu for “Field name”. The type of this field is a Multiple lines of text-field. Typically, a site column for domains would be created, so that the domains can be fetched from there, as shown in the image below:

A useful case for this scope is if there are certain domains that under no circumstances can share in the items on the solution. Consider Company A and Company B. Company B is a rival of Company A, and a project team of Company A can therefore under no circumstances share documents or items with any email domains of Company B. All known domains of Company B is therefore entered in the Domains field, thereby restricting sharing with Company B.

Regardless of whether the Static or Dynamic type is chosen, the "Sharing Capability Type" is what determines how users invite people outside the organization to access the content being shared. The options available in the "Sharing Capability Type" drop-down menu always respects tenant settings.

This means that if e.g. "Anonymous Access - anyone with the link" is not ticked in the sharing settings of the tenant, the "External users and guests" option in the Sharing Capability Type drop-down menu will not be accessible. It will, however, still be displayed in the drop-down menu. An example of this is exemplified in the image below:

The tenant level sharing settings can be accessed through the SharePoint admin center. This center can be navigated to in a browser by typing "https://[DOMAIN]-admin.sharepoint.com".

In the Default Sharing Link Type drop-down menu,  the administrator can choose which type of link should be created by default when users receive links.

Available options are:

• Default Link Type (This is equivalent to inheriting the default link type from what is set on tenant level. This default can be set in the SharePoint Admin Center)
• Direct (Only the receiving account can use this link)
• Internal (Users from within the organization can use the generated link)

The Default Sharing Permission Type allows the administrator to choose which permissions are granted by default when links to items are shared.

Sharing Permission Types can be set to:

• Default Permission Type (Permissions are inherited from the default setting on tenant level. The default tenant permission can be set in the sharing options in the SharePoint Admin Center)
• View (Users receiving a sharing link have permission to only view the item)
• Edit (Users receiving a sharing link have permission to both view and edit the item)

Sharing Type allows the administrator to choose whether to add domains to either a block- or allow list.

This list of domains specifies who can and cannot be shared with in the following way:

• None: Links can be shared with anyone
• Block: Links cannot be shared with the domains listed in the domains field (manually input if the "Static" rule type is chosen, or pulled from a field if "Dynamic" rule type is chosen)
• Allow: Only domains listed in the domains field can access shared links (manually input if the "Static" rule type is chosen, or pulled from a field if "Dynamic" rule type is chosen)

The associated site for the business module entity. For this scope, the personnel for which the rule applies as well as the permission level must be set. Available default permission levels are;

• Full control: Has full control.
• Design: Can view, add, update, delete, approve, and customize.
• Edit: Can add, edit, and delete lists. Can view, add update, and delete list items and documents.
• Contribute: Can view, add, update, and delete list items and documents.
• Read: Can view pages and list items and download documents.
• View Only: Can view pages, list items, and documents. Document types with server-side file handlers can be viewed in the browser but not downloaded.

If you add custom permission levels these will also be available and supported by WorkPoint

One or more lists on the business module entity site. For this scope, the personnel for which the rule applies, the list(s) of the business module entity site which the security rule applies to, and the permission level must be set. Available default permission levels are;

• Full control: Has full control.
• Design: Can view, add, update, delete, approve, and customize.
• Edit: Can add, edit, and delete lists. Can view, add update, and delete list items and documents.
• Contribute: Can view, add, update, and delete list items and documents.
• Read: Can view pages and list items and download documents. View Only: Can view pages, list items, and documents. Document types with server-side file handlers can be viewed in the browser but not downloaded.

If you add custom permission levels these will also be available and supported by WorkPoint

Using this scope, it is possible to set permissions on individual documents or items, e.g. documents with a yes/no-choice column “Confidential” and a value of “yes” could be restricted to only be accessible for the project manager.

It is very important to realize that this is not an option that should be used on every single document. It should instead be used on individual documents/items or small selections of documents/items. The reason for this is that using this option on many documents/items can seriously affect the performance of the solution. Therefore, this option should only be used on one-site-collection-pr-entity cases where group-based security is activated. Another reason for this is that it dramatically reduces the amount of manual maintenance required.

Depending on the type of security rule is chosen, the administrator needs to fill out either the “Users or groups” field or the “Field name” field. Next, the list(s) on the business module that the rule should be applied to must be chosen. The administrator also needs to choose which field should be considered the “Limitation field” and a “Limitation value”. The limitation field can either be a yes/no-choice field, or it can be controlled through managed meta data. In the case of a yes/no-choice limitation field, this could e.g. be a column called “Confidential”, and the rule could be set up in such a way that documents/items with a Confidential-value of “yes” is only accessible to the Project Manager.

In the case of a rule based on managed meta data, one could set up a colour code throughout an entire chain from Tenant, through the site collection and sites, all the way down to the individual documents and items. Access to these could be controlled via the colour code.

The Email Manager Journal scope defines who will have access to the Email Manager journals of entities.

Depending on the "Type" selection, you must select either a person/group, or a person/group field on the business module to determine to whom this security rule applies.

You must also select an "Email Manager Journal Permission Level", which will be granted to the selected person/group or personnel in the person/group field. The options for the Email Manager Journal Permission Level are:

• Full control: Users which this permission level can add, delete, and read e-mails in the journal.
• Contribute without delete: Users with this permission level can add and read e-mails in the journal.
• Read: Users with this permission level can read e-mails in the journal.

An example of a complete Email Manager Journal security rule could look like this:

Through the Security Settings dashboard it is possible to add conditions to each individual rule if needed. It is also possible to use a collective general condition which governs all security rules. If a general condition is set, both that one and sub-conditions (if set) must be satisfied for the security rule to activate.

It is also possible to reuse a condition on several different security rules, minimizing the need to do configuration.

The administrator can add conditions by clicking the “Add condition” button (①):

The interface for adding conditions is shown in the image below:

Activation conditions can run in 3 different modes, which are explained in the following sections.

If “Always” is chosen, all security rules will always activate.

If “Simple” is chosen, all security rules are controlled by a single condition (As in the previous system).

If “Advanced” is chosen, you can assign a condition to each security rules. Furthermore, if “Advanced” is chosen, an activation condition must be set when adding a new security rule.

The user interface for the advanced setting looks like this:

1. Advanced is chosen.
2. A couple of activation conditions have been added to the list.
3. The “Add condition” button allows the user to add more conditions.

After having activated Advanced Mode, the “Add security rule” interface now has an additional field to be filled out. This field is called “Activation Condition”. From the drop-down menu, the activation condition that should be fulfilled in order to activate the security rule can be chosen. An example is shown below:

If a security rule has been added without Advanced Mode being active, the rule has no activation condition assigned. Should Advanced Mode later be activated, the rule can be edited and outfitted with an activation condition afterwards. This means that you can always go back to security rules and provide them with activation conditions if they were previously created without one, provided that Advanced Mode is activated.

If e.g. a certain group of people should have Read access to a library under normal circumstances, but Contribute access to the same library if the entity of the library is in a certain stage, a general rule of thumb is to create the Read access security rule without an activation condition, and then another rule for Contribute access with an activation condition which checks the stage of the entity. In this case, the base access level for the group is Read on the library, unless the entity enters the given stage, in which case, the group is granted Contribute access.

Security Replication refers to manually triggered, or interval automated, jobs that replicate the configured security settings and permissions onto entities of the business module.

To access the Security Replication settings, follows these steps:

1. Access the WorkPoint 365 Administration Dashboard
2. Click the header of the business module for which you wish to access the Security Replication settings
3. Click “Security Replication” from the list

The interface for Security Replication is shown in the image below:

1. In the WorkPoint Security Scopes section, you can select which scopes of the master site collection to replicate security. It is generally good practice to only select the scope(s) where you have made changes to permission setups, in order to optimize performance of the job. Note that the options in WorkPoint Security Scope is dependent on the architecture of the business module you are configuring. The image demonstrates the scopes for One entity per site collection modules. For modules using the Multiple entities per site collection architecture, you cannot select the "SharePoint Group", "Office 365 Group" or the "Sharing" options. The image demonstrates the settings for modules using the One entity per site collection architecture. On modules using the Multiple entities per site collection architecture, this entire section is not applicable and is therefore not shown.
2. In the Site Collection Security section, you can select which security objects to replicate from the root site collection to the selected replication scope. The security replication will respect the security settings currently configured on the business module, i.e. they will not be overwritten. Note that the options in Site Collection Security is dependent on the architecture of the business module you are configuring. If you need to synchronize objects from the root site collection to bucket sites related to a Multiple sites per entity module, you can perform a Site Collection Synchronization.
3. In the Replication Scope, you can select which entities on the module to replicate security onto. Dependent on your selection, you may need to provide more information. Here's an overview of the different replication scopes and their required information:

All entities

• No additional selection required

Single entity

• The internal ID of the entity to be synchronized must be provided.

Start from entity

• The internal ID of the entity to begin the synchronization from. This entity and all subsequent entities will have security replicated onto them per your selections.

View

• A view from the business module must be selected. You can select between the currently configured views on the business module.

CAML

• A CAML query which selects the entities you want to replicate security onto must be provided in the CAML editor. You can write your own CAML query and use the "Validate" button to validate your query, or you can load a CAML query from a view on the business module by selecting a view and clicking the "Load CAML from View button.

Buffer Sites

• No additional selection required.

4. In the Schedule section, you can select when to run the security replication. Dependent on your selection, additional information may be required:

Run now

• No additional information required. The job will run immediately upon clicking the "Replicate" button.

Schedule

• A start Date and Time must be selected (UTC time). Once a start date and time has been selected, you can schedule the job by clicking the "Replicate" button. The job will run once the selected date and time comes around.

It is possible to schedule jobs for WorkPoint to replicate security settings by clicking the "Schedule now"-button.

In the example below, two jobs have been set up:

A "Full Security Replication" job has been set up to run only once, and its state is "Completed".

An "Incremental Security Replication" job also exists. This job runs once every hour, and applies any changes made since last security replication.

One thing that happens in the background of WorkPoint Security is an event based security replication whenever changes are made to fields that have security rules applied to them. An example of this would be if a specific field of a field of e.g. a list or a document has one or more security rules applied to them. If a user makes changes to that field, am incremental security replication is automatically triggered. This is what is referred to as event-based security.

1. Structural hierarchy

Structural hierarchy refers to the structural hierarchy of components of a SharePoint/WorkPoint solution. Components of a standard SharePoint solution are nested in a downwards hierarchical structure shown in this image:

WorkPoint expands on the above structure and adds a link between a SharePoint list item to another site. E.g. a Projects business module is actually a SharePoint list holding items which points to project sites. This expanded structure is illustrated in the image below:

2. Business Module

A business module in WorkPoint terms is a SharePoint list containing items which points to various types of sites. A Companies business module is a SharePoint list containing items which points to sites for individual companies. In the same way, a Projects business module is a SharePoint list containing items which points to sites for individual projects.

3. Entity

An Entity is a term for a SharePoint list item in a business module. E.g. each individual project in a Projects business module list is considered an Entity.

4. List/Library

Lists and Libraries are containers for documents, items, etc. They are located on a Site. You can refer to the SharePoint hierarchy structure image for an overview of the components of a SharePoint solution.

5. Document/item

A document or item is at the lowest level of a SharePoint solution. Documents and items are stored in lists or libraries. You can refer to the SharePoint hierarchy structure image for an overview of the components of a SharePoint solution.

The following list explains a couple of  best practices with regards to security in WorkPoint.

• Use AD or SharePoint groups when assigning permissions where possible.
  • For instance when a record manager with permissions to see all content is to be changed, it's much faster and  easier to change the users in a group in the AD or on the Root site collection of WorkPoint, than it is to update each individual  entity in WorkPoint.
• Reduce the amount of individual rules my letting SharePoint inherit permissions where possible.
  • When assigning permissions to lists, try to assign the permissions on the site scope, and let the lists inherit from the site, and only specify in the rule which lists that need to have specific permissions.
• Avoid conflicting permissions.
  • Avoid creating security rules that give a user or group different permissions on the same scope at the same time. Use activation conditions to avoid this.