ON THIS PAGE:
Security in P2 Explorer broadly works by applying cascading privileges over an interlinked set of modules, resources, and objects, which correspond to various features in P2 Explorer.
P2 Explorer contains a series of modules, which refer to a capability of the software, such as Security, Server, Explorer, Sentinel, Commentary, and Shift Log. Each module contains different resources, and a resource is a collection of objects of the same type.
Here is an overview of how modules, resources, and objects in P2 Explorer are related:
The table below shows the resources belonging to each module.
| Server | Explorer | Sentinel | Commentary |
|
|
|
|
Terminology
| Module | The part of the software that allows P2 Explorer to provide various capabilities. Includes Server, Explorer, Sentinel, Commentary, and Shift Log. When assigning module-level privileges, these are admin privileges that allow super-user access to the module. This includes all privileges for all resources, plus a variety of admin-specific tasks. |
| Resource | A collection of a particular type of object, such as workspaces. Each module has a set of resources that represent discrete objects within a module. E.g. The Explorer module has Forms, Styles, Workbooks and Workspaces resources. |
| Object | An individual instance of a resource, such as Workspace A, Workspace B, etc. |
| Privilege | A level of access permission that can be applied to modules, resources, and objects. E.g. Admin, View, Write, Edit, Delete. |
| Role | A set of privileges for accessing a module's features, which are inherited by individual users who have been assigned to this role. E.g. A Server Administrator role would have the Admin privilege for the Server module. |
Here is what this looks like in the Role Privileges page:
Default Security
By default, all users belong to the Everyone role, which has view access to all objects for all resources for all modules. The diagram below shows the default access available for all roles.
Key Points:
- All users must belong to a role in order to be granted privileges. By default, all users are added to the Everyone role.
- The Everyone role has implicit view privileges for all objects in the system.
- Permissions are granted explicitly on top of the default view privileges for Everyone. So users (by way of roles) can be granted other privileges in addition to the default view privileges.
- Module-level (admin) privileges override resource-level privileges, which in turn override object-level privileges.
Object-Level Security
The Everyone role has 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 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.
In the scenario above, the grey lines indicate that default security applies. There are no explicit privileges on Object 1, so all roles have the View privilege.
However, Role 1 has been given an explicit privilege for Object 2. In doing so, the implicit default privilege for Roles 2 and 3 no longer apply, and they are now unable to view the object in the system. This mechanism is how administrators can lock down tags, workspaces, and other objects in the system.
Resource-Level Security
Explicit security at the resource level applies to all objects of that type in the system, regardless of the object privileges. Additional privileges can be granted on an individual object for other roles so other users can access it.
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 object privileges.
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.
Module-Level Security
Module-level security is security at the admin level. There are 2 types of administrator:
- Security administrator - has access to the Security section of Server Management, and is able to create users and roles, and assign module- and resource-level privileges to roles.
- Module administrator - has "superuser" access to all of the resources and objects associated with that particular module, and is able to assign object-level privileges to users.
The diagram above illustrates a module administrator. In this scenario, Role 4 has been granted an explicit Admin privilege for the entire module. They therefore have the highest level privileges for all of the objects in all resources of that module. They are a "superuser" of the module.
Role 1 has been granted an explicit privilege over Resource 1, so they have that privilege for all of the objects in Resource 1. Role 1 also has default access to Object 3. Object 4, however, has been locked down so it cannot be accessed by Role 1.
Role 3 has been granted an explicit privilege over Object 4. So Role 3 is the only one who has access to Object 4, aside from the admin role. Role 3 also has default access to all other objects, because they haven't been explicitly locked down.
Role 2 has not been granted any additional privileges over the default view privilege. So Role 2 has default access to Objects 1, 2, and 3, because they haven't been explicitly locked down. However Object 4 is locked down so it cannot be viewed by Role 2.
Users & User Groups
During initial installation, users are usually imported from Active Directory (AD). These users can log in automatically using their Windows domain credentials.
If AD has these users sorted into groups, then these will also be imported into P2 Explorer as User Groups. User Groups cannot otherwise be created or modified in P2 Explorer.
Users can also be manually created, either as Windows users or as a user that requires a user name and password to log in ("Forms" user).
When a user is created as a Windows user (either manually or via AD Sync), they can log in by clicking the green Automatic Login button.
When a user is created as a Forms user, they can log in by entering their credentials into the username and password fields and clicking the blue Login Using Password button.
Sessions and UI Refresh Behaviour
Users will get updated privileges after logging out, and every hour when the security token is renewed. So if a user's privileges have changed, they will receive the privileges within an hour or after logging out and logging back in.
For better security, P2 Explorer has two ways of checking that the logged in user has valid credentials.
Every hour:
After an hour, the system will check the logged in user's credentials and if valid, will automatically log them back into the system. The user will not notice any difference, unless the user is logged into a different domain. If this is the case, a popup screen will flash briefly while the user is being logged back in.
Note: Forms users will be logged out every hour, unless they select the Stay logged in for 30 days check box on the login screen.
After 30 days:
After 30 days, the system will need to re-authenticate the user.
For Windows users, this is seamless and the user will automatically be logged back in. If the user is logged into a different domain, a popup screen will flash briefly while the user is being logged back in.
Forms users will see a popup window, in which they need to re-enter the login credentials.
Release History
- How Security Works (this release, 4.9.1):
- Shift Log module
- Named List items