Follow

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.6. Site

           3.3.3.7. List

           3.3.3.8. Documents/items

   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

1. Introduction

WorkPoint has for a long time had the ability to control permissions e.g. using security rules, which dynamically applies rules based on entities’ Master Data. This is a strong tool. However, experience also shows that this approach often leads to an undesirable number of breaks in security inheritance, which should not be necessary. Furthermore, a series of new requirements and demands related to security have arisen, which are also addressed with this package.

Using WorkPoint it is possible to control all aspects of permissions to your data using rules and policies. The goal is to ensure that the end users does not need to know anything about permissions. Instead, based on user roles, permissions will automatically be assigned. For example, the user would specify different roles on a project (e.g. project manager, project team, assistant, external users). Based on these roles, the system can grant permissions according to the business need.

WorkPoint also ensures full control and governance of permissions. If users change permissions unintentionally, the system will ensure that permissions are rolled back according to your settings.

Please note, that WorkPoint does not change limit and boundaries defined by Microsoft. Limits regarding break of permission inheritance must still be respected. Therefore, it is important that you understand the effect of your configuration on your solution. Although WorkPoint makes it very easy to control your permissions, WorkPoint also makes it possible to automate roll out of complex permission schemes that could affect your solution in an undesirable manner.

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

2. WorkPoint Structural Hierarchy

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.

3. Security Settings

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

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

From here the user can edit the security permissions 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.

   3.1. Business Module Entity

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

Each of the options are explained in the following sections.

       3.1.1. Manual Security

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

       3.1.2. Inherit from Current Business Module

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. This feature 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.

       3.1.3. Inherit from Parent Business Module

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

       3.1.4. Use Security Rules

Permissions for entities are based on rules with entity scope.

   3.2. Business Module Entity Site

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

Each of the options are explained in the following.

       3.2.1. Manual Security

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.

       3.2.2. Inherit from Current Business Entity

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.

       3.2.3. Use Security Rules

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

   3.3. Adding a Security Rule

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

       3.3.1. Active

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

       3.3.2. Type

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

           3.3.2.1. Static

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”.

           3.3.2.2. Dynamic

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.

Note that if “Dynamic” is chosen, the field that specifies the personnel that this rule applies to is named “Field name”.

           3.3.2.3. Inherit

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.

       3.3.3. Scope

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.

           3.3.3.1. Entity

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

           3.3.3.2. Wizard

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.

           3.3.3.3. SharePoint Group

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.

           3.3.3.4. Office 365 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.

           3.3.3.5. Sharing

[PLEASE NOTE THAT THIS FEATURES HAS BEEN TEMPORARILY DISABLED DUE TO ISSUES WITH MICROSOFT APIs]

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.

               3.3.3.5.1. Static

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.

               3.3.3.5.2. Dynamic

For the dynamic type, domains can be retrieved from an entity field, which can be specified in the drop-down menu for “Field name”. 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.

           3.3.3.6. Site

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

           3.3.3.7. List

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

           3.3.3.8. Documents/items

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.

   3.4. Activation Conditions for Security Rules

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.

       3.4.1. Always

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

       3.4.2. Simple

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

       3.4.3. Advanced

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.

4. Security Replication

Security Replication refers to manually triggered, or interval automated, events that replicate the configured security settings and permissions onto each entity 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:

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.

   4.1. Types of Security Replication

The administrator can also choose to run security replication now by clicking one of the Start Replication-buttons. The administrator has three choices:

   1. Start replication on entity

This button starts a security replication job for the current entity. For this replication, the internal ID of the entity that you wish to run security replication for must be put into the available field to the right of "Run Security Replication now".

   2. Start incremental replication

Incremental mode only applies any changes made since the last run. It does this by searching through SharePoint's change log to see which changes have been made. If it sees that changes have been made to entities that have security rules applied to them, a replication is run that that entity.

   3. Start full replication

Full mode maintains permissions for all entities in WorkPoint 365.

5. List of Terms

  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:

  1. 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.

  1. Entity

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

  1. 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.

  1. 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.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments