Locking Down an Object

This article applies to versions 4.6 and later of P2 Explorer.

All roles have implicit view privileges for all objects in the system, which is designed to allow security administrators to apply object-level privileges to certain roles. When locking down an object, you will need to remove this privilege from each role.

When applying object-level privileges, it is important to remember the cascading nature of privileges applied at the resource-level. If a role has explicit View privileges on a resource, all users with that role can view all objects for that resource, regardless of the privileges at the object level. 

TOP TIP

If you intend on doing a lot of object-level security, avoid using resource-level security.

 

In the scenario above, Role 1 has been granted an explicit privilege for the resource. Roles 2 and 3, while not given resource privileges, still have default privileges for Object 1.  

However, Role 3 has been given an explicit privilege for Object 2. In doing so, Role 2 is effectively locked out and cannot see Object 2. However, Role 1 still has access to Object 2 because the role has privileges at the resource level, which overrides the object-level privileges.

Related: How Security Works, How Roles Work, How Object Access Works

When locking down an object (such as a workspace), you will initially notice that default view privileges have been granted to all roles, even if this has not specifically been defined for the role at the resource level. It is these default privileges that we need to pay attention to.

From this (in the object e.g. workspace):

To lock down an object, you need to remove all of the View privileges for all roles, except for the role you want to have access.

To this:

Exception: You will not be able to remove the blue inherited privileges. These indicate that the privilege is inherited from an explicit module- or resource-level privilege, such as an admin-level privilege.

While it's easy to understand admin-level privileges, it's the resource-level privileges that can trip you up when trying to secure an object.  

Related: Add an Administrator

For example, if one of your roles has resource-level view over an object you are trying to secure, you will not be able to remove that privilege at the object level. In the example below, all users with the Workspace Editor role have explicit View privileges for all workspaces, at the resource level. This is indicated by the blue dot for the Workspace Editor. This cannot be removed at the object level, so these users will still be able to see all pages in all workspaces.


Example: Locking Down a Workspace

In this example, we show you how to lock down an object. Let's use workspaces as an example — and Operations as the workspace object we want to lock down. 

Step 1. Server Management Role Privileges

The first step is to make sure that no roles have resource-level privileges for workspaces. This step must be performed by a Security administrator.

The exception is the administrator role for the module which owns the object you are locking down. In this case, you might allow Administrators and Explorer Administrators resource-level privileges, but no other role.

You will need to go through each and every role, one by one, and make sure that all privileges for workspaces are off. It may be easier to first check the workspace to see which roles are affected.

Related: Change a Role's Privileges

Step 2. Object Privileges

This step must be performed by an Explorer administrator.

Open the module in which the object is located. In the case of workspaces, these are located in Explorer. However other objects, such as datasources, are located in other modules and the privileges can be found alongside the configuration options (for the datasources example, these are in Server Management > Configuration > Datasources).

Open the workspace you want to lock down, and click the  Settings button.

Take note of the View privileges, and especially the blue ones. These are the roles that have the privilege applied at the resource or module level. If you do not want any of these roles to see this workspace, go back into Role Privileges and remove it from the role (see Step 1 above).

Next, you will notice that the remaining roles all have explicit (green) view privileges for the workspace. This is because of default security, whereby all users have view access to all objects. We can override this default security here.

Related: Default Security for Everyone

For each role, except the Managers role, go through and untick the green View privilege. The only role want to be able to view this workspace is the Managers role, so that will remain green. 

Then, click Save.

You have now locked down the Operations workspace so that only Managers and some administrators are able to view it.

 

2 Comments:

  1. This tutorial shows how to lock down a workspace, is there a tutorial to lock down a page or a trend as I did the search and found none.

  2. Hi Lan, pages and trends are locked down according to the workspace they have been saved in. It's not possible to lock down pages and trends individually. If you would like them to have different privileges to what is on the workspace, you could save a copy to a different workspace and secure that workspace separately.

Comments are closed