Access control ensures that people using Analytics can access only the data they are allowed to see. Analytics provides access control through an integrated security framework that includes:
Authentication – Restricts access to identified users and protects that access with passwords. Defines roles for grouping users and assigning permissions.
Authorization – Controls access to repository objects, pages, and menus based on users and roles.
Data level security – Defines row and column level permissions to access your data. Row and column level permissions can be defined and enforced in Domains.
The first part of security is to define user accounts and secure them with passwords. Users must log in with their user ID and password so that they have an identity within Analytics. Analytics stores user definitions, including encrypted passwords, in a private database. Administrators create, modify, and delete user accounts through the administrator pages.
Analytics also implements roles that can be assigned to any number of users. Roles let administrators create groups or classes of users that are granted certain permissions. For example, administrator privileges are granted by the ROLE_ADMINISTRATOR role. A user can belong to any number of roles and receive the privileges from each of them. Analytics stores role definitions in its private database.
Analytics relies on the open source Acegi security framework, which has configurable options for:
External authentication services such as LDAP (used by Microsoft Active Directory and Novell eDirectory)
Single sign-on using JA-SIG's Central Authentication Service (CAS)
Java Authentication and Authorization Service (JAAS)
Container security (Tomcat, Jetty)
Anonymous user access (disabled by default)
Analytics also supports these encryption and authentication standards:
HTTPS, including requiring HTTPS
The Acegi framework is readily extensible to integrate with custom and commercial authentication services and transports.
Authentication occurs by default through the Web user interface. Analytics can automatically synchronize with an external authentication service. The external users do not need to be created manually in Analytics first. Both users and roles are created automatically in Analytics from their definitions in an external authentication service.
With a user's identify and roles established, Analytics controls the user's access in several ways:
|Menu Options and Pages||The menus that appear in Analytics depend on the user's roles. For example, only users with the administrator role can see the Manage menu and access the administrator pages. By modifying Analytics' configuration, you can modify access to menus, menu items, and individual pages.|
|Organization Scope||Users belong to an organization and are restricted to seeing resources in that organization. Organizations have their own administrators, but they see only the users, roles, and resources from their organization. When Analytics is configured with multiple organizations, they are effectively isolated from each other.|
|Resource Permissions||Administrators can define access permissions on every folder and resource in the repository. Permissions are defined for every role and every user, or they can be left undefined so they are inherited from the parent folder. For example, users may have read-write access to a folder where they create reports, but the administrator can also create standard reports in the same folder that are set to read-only. Permissions are enforced when accessing any resource either directly through the repository interface, indirectly when called from a report, or programatically through the Web services.|
|Administrator Privileges||Analytics distinguishes between reading or writing a resource in the repository and viewing or editing the internal definition of a resource. For security purposes, granting a user read or write permission on a resource does not allow viewing or editing the resource definition. For example, users need read permission on a data source to run reports that use it, but they cannot view the data source definition, which includes a database password. Only administrators can create, view, or edit the definition of a resource and its internal components.|
|Data-Level Security||Data-level security defines what data can be retrieved and viewed in a report, based on the user name and roles of the user who runs the report. For example, a management report could allow any user to see the management hierarchy, managers to see the salary information for their direct employees, and only human resource managers to see all salary information.|
Permissions on folders and resources determine what users see in the repository and the actions they are allowed to perform. In the following table, the actions granted for each permission include all of the actions granted for permissions above it, except for the No Access permission. The actions granted for each permission strictly exclude all of the actions granted for permissions below it.
|Permission||Actions Granted on Repository Folders and Resources|
|No Access||Users cannot see or access the folder or resource, either directly or indirectly.|
|Read Only||See the folder or resource in any Analytics dialog, see the properties of a folder or resource, copy a folder and all of its readable contents, copy resources individually or in bulk, view (run) a report or dashboard, run a report in the background, schedule a report to run later|
|Read + Delete||Cut (move) a folder and all of its contents, delete a folder and all of its contents, cut (move) resources individually or in bulk, delete resources individually or in bulk|
|Read + Write + Delete||Paste into a folder (copy or cut), save a new Ad Hoc report or dashboard in a folder, save the output of a scheduled report in a folder, rename a folder or resource and change its description string, open an Ad Hoc report in the Ad Hoc editor or a dashboard in the designer, modify and overwrite an existing Ad Hoc report or dashboard|
|Administer||Set the permissions (by role and by user) or a folder or resource|
|Administer and ROLE_ADMINISTRATOR||Add (create) a resource in a folder, edit a resource (for example, the components of a report unit or a Domain)|
Permissions apply to access when browsing or searching the repository, as well as any dialog that accesses the repository, such as when browsing folders to save a report.
Copying does not preserve the permissions on an object. Users may copy a read-only object, paste it into a read-write folder, and then edit the object.
Copying and cutting (moving) actions can only be completed if the user has Read + Write + Delete access to a folder in which to paste the objects.
Cutting, deleting, and setting permissions on folders is allowed only if the user has the same permission on all folder contents. Cutting and deleting resources in bulk is allowed only if the user has at least Read + Delete permission on all selected resources.
Deleting a resource or the contents of a folder is allowed only if no other resources rely on them.
According to the permission architecture, there is a permission setting for every user and role on every folder and resource in the repository. To simplify the definition of permissions, Analytics supports the inheritance of permissions from the parent folder of a folder or resource. If no permission is explicitly defined for a user or role on a given folder or resource, the user or role has the same access permission that is defined on the parent folder. When a permission is defined explicitly, that permission is enforced, regardless of those on the parent folder.
Using this mechanism, administrators can manage large hierarchies of content and keep them secure. When the administrator sets a permission explicitly, that permission for a given user or role is inherited recursively by all of the folder's contents and subfolders, unless they have an explicit definition of their own. Permissions that are assigned on an organization's top folder are inherited across the entire organization. Permissions that are set on the root folder or Organizations folder by the system admin are inherited across multiple organizations.
For example, the system admin can make all organizations read-only by default to ordinary users, and each organization admin can make specific folders writable so that users can store their reports and output.
Because permissions can be assigned to both users and roles, a user belonging to one or more roles may have multiple permissions defined or inherited on any given folder or resource. In fact, every permission must be defined on the root, even if it has the default value of No Access, and therefore every role- and user-based permission on every folder and resource has a setting through inheritance. Therefore, for every folder or resource, every user has a their own user-based permission and the permission assigned to the ROLE_USER role.
Permissions in Analytics are strictly cumulative, meaning that the least restrictive among the set of all permission applies. Even if a more restrictive permission, such as No Access, is set explicitly, the less restrictive permission such as Read-Only applies, regardless of whether it is inherited or set explicitly.
The Analytics authorization architecture distinguishes between administrators and all other users. Administrators are defined as users with either ROLE_SUPERUSER, ROLE_ADMINISTRATOR, or both. By design, system administrators with the ROLE_SUPERUSER always have irrevocable Administer access to the entire repository, including to the contents of every organization. The system administrator cannot modify the permissions for ROLE_SUPERUSER, to prevent being locked out or unable to administer some resource. Therefore, the system admin can set permissions for all other users, on any folder or resource, and in any organization if necessary. In particular, the system administrator can modify permissions for ROLE_ADMINISTRATOR, for example to share some resources across all organizations by making them read-only to everyone, including the organization admins.
Organization admins are organization users with the ROLE_ADMINISTRATOR role. By default, organization admins have the Administer permissions to everything within their organization, except what the system admin has changed to a lesser permission. However, organization admins cannot change the permissions granted to ROLE_ADMINISTRATOR, to prevent them from overriding the settings of the system admin and from locking themselves out of a folder or resource.
For all other users, the default permission at the root is No Access and any permissions must be explicitly defined. In practice, the default installation of the repository contains sample data with permissions that allow the sample users to access folders and resources. We recommend you familiarize yourself with the permissions mechanism by viewing and setting permissions in the sample data, as described in the following section.
Administrators can assign permissions to access any folder or resource throughout the repository. Users with the Administer permission on a folder can assign permissions to that folder and any contents that inherit the permission. Users granted Administer permission to a resource can only set the permissions on that specific resource.
To set permissions on a folder or resource in the repository:
Log in as a user with administrative privileges.
Select View > Repository, and then locate the folder or resource.
Right-click the folder or resource, and then select Permissions from the list of options.
The Assign Permissions by Role interface shows the existing role-based permissions in effect for the folder or resource. In systems with multiple organizations, the roles displayed only include those in the scope of your user. In the default single organization, the organization admin cannot see the permission for ROLE_SUPERUSER.
Permissions that are inherited are indicated by * (asterisk).
For each role you want to grant access, select a value form the Permission Level list of options.
Among the possible values, the permission of the parent folder is also indicated by * (asterisk). Setting the permission to the inherited value is the equivalent of removing an explicit permission.
There are two special cases.
You cannot explicitly set the permission level that in inherited from the parent folder, at least not directly. You need to temporarily change the permission level on the parent folder, then set the explicit permission, and finally set the parent folder's permission back to the original value.
If none of the options in the drop-down are highlighted, the folder and its parent have been independently set to the same value. To reset the permission level so that it once more inherits its parent folder, select a different permissions level and click Apply; then select the permission with the asterisk and click Apply again.
Click Apply to save your changes before assigning permissions by user. If you have finished, then click OK to save and return to the repository view.
To assign permissions by user, click by User.
The Assign Permissions by User interface shows the existing user-based permissions in effect for the folder or resource. In systems with multiple organizations, the users displayed only include those in the scope of your user. In the default single organization, the organization admin cannot see the permission for superuser. Permissions that are inherited are indicated by * (asterisk).
There are no user-based permissions defined by default. In this case, all access permissions have been defined through roles.
For each user you want to grant access, select a value from the Permission Level list of options.
Click Apply to save your changes and stay on an Assign Permissions page. If you have finished, click OK to save and return to the repository.
Click Cancel to return to the repository without changing permissions.
Once you have configured users, roles, and permissions, Zenoss recommends that you test the permissions granted to a few representative users. Testing is also recommended when you add new users, roles, and resources, and when you make any major modifications to your access control configuration.
To test user permissions:
Log in as an administrator.
Select Manage > Users, and then select the user whose access permissions you want to test.
Click Login as User.
The selected user's Home page appears.
Select View > Repository, navigate to the desired folder, and verify that Analytics displays the expected folders and resources.