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<\/em> View privileges on a resource<\/strong>, all users with that role can view all objects for that resource, regardless of the privileges at the object level.\u00a0<\/p>\n If you intend on doing a lot of object-level security, avoid using resource-level security.<\/p>\n<\/div>\n <\/p>\n 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.\u00a0\u00a0<\/p>\n 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.<\/p>\n Related: How Security Works<\/a>, How Roles Work<\/a>, How Object Access Works<\/a><\/p>\n 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.<\/p>\n From this (in the object e.g. workspace)<\/strong>: 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.<\/p>\n To this<\/strong>: Exception<\/strong>: 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.<\/p>\n 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.\u00a0\u00a0<\/p>\n Related: Add an Administrator<\/a><\/p>\n 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.<\/p>\n In this example, we show you how to lock down an object. Let's use workspaces as an example \u2014 and Operations<\/em> as the workspace object we want to lock down.\u00a0<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/strong><\/p>\n Related: Change a Role's Privileges<\/a><\/p>\n This step must be performed by an Explorer administrator.<\/p>\n 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<\/em>).<\/p>\n Open the workspace you want to lock down, and click the Take note of the View<\/strong> privileges, and especially the blue<\/strong> 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<\/strong> and remove it from the role (see Step 1 above).<\/p>\n Next, you will notice that the remaining roles all have explicit<\/strong> (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.<\/p>\n Related: Default Security for Everyone<\/a><\/p>\n![\"\"](\"https:\/\/oihelp.corporate.ifs.com\/help\/wp-content\/uploads\/2018\/04\/security-46-resource.png\")
<\/a><\/p>\n
\n<\/a><\/p>\n
\n<\/a><\/p>\n<\/a><\/p>\n
\nExample: Locking Down a Workspace<\/h2>\n
Step 1. Server Management Role Privileges<\/h3>\n
<\/a><\/p>\nStep 2. Object Privileges<\/h3>\n
\u00a0Settings<\/strong>\u00a0button.<\/p>\n<\/a><\/p>\n