Permissions on folders and resources determine what users see in the repository and what 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 can never see or access the folder or resource either directly in the repository or indirectly when running a report, and dashboard. |
Execute Only | Users can never see the folder or resource in the repository, but the reports, dashboard, or OLAP views that they run can access them. |
Read Only |
|
Read + Delete |
|
Read + Write + Delete |
|
Administer |
|
Administer and ROLE |
|
Permissions apply when browsing or searching the repository, as well as when using any dialog that accesses the repository, such as when browsing folders to save a report.
Inheriting Permissions
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, JasperReports Server 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.
...
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.
Cumulative Permissions
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.
How does JasperReports Server determine the effective permission from the many that apply? Permissions in the server 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.
Administrator Permissions
The JasperReports Server authorization architecture distinguishes between administrators and all other users. Administrators are defined as users with either ROLE_SUPERUSER (available in the professional edition of JasperReports Server only), 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, like the default jasperadmin created in every organization. By default, organization admins have the Administer permissions to everything in 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.
Execute-Only Permission
As in file systems, execute-only permission in JasperReports Server allows running reports, dashboards, and OLAP views to access a resource, but keeps the resource from appearing in the repository.
...
As with all other permissions, execute-only permission is either role-based or user-based, so that certain users may access a resource from a running report, but not others.
 | If you have data or sensitive content in a resource, always set No Access permission for users or roles that must not be able to access it. Hiding a resource with execute-only permission does not protect against access, because malicious users who find the resource ID may be able to create a report, dashboard, or OLAP view that extracts the sensitive content. |
Default User Permissions
For all non-administrator 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 a mix of no access, execute only, read only, and read-write permissions that allow the sample users to access folders and resources. The sample permissions demonstrate a common approach to permissions, allowing users to see the resources they can access and hiding the ones they can’t, while administrators have full access.
We recommend you familiarize yourself with the permissions mechanism by viewing and setting permissions in the sample data, as described in the following section.
Setting Permissions
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.
...
The Permissions dialog opens. It shows the permissions in effect for the selected object. By default, it first shows the permissions given to roles. Permissions that are inherited from the object’s parent are indicated by an asterisk (*).
 |
Permissions Dialog Showing Permissions by Role |
In the figure “Permissions Dialog Showing Permissions by Role”, you can see the default role-based permissions on the sample Input Data Types folder as seen by the organization admin. Members of certain roles can see and modify the input data types stored in this folder; these roles likely correspond to users such as data analysts. Regular users have execute only permission so they do not see this folder, but the reports they run can access its contents. Administrators cannot change the permission for their administrator role or user name, to prevent them from removing their ability to set permissions.
...
In the figure “Permissions Dialog Showing Permissions by User”, you can see the default user permissions on this folder. In the default installation, all permissions are defined by role; therefore, all user permissions are No Access inherited from the root. The figure shows a read-only permission being granted to the sample end user. This gives the user joeuser the ability to see but not modify the Input Data Types folder and its contents. For all other end users, however, the folder is still execute-only due to the settings in the figure “Permissions Dialog Showing Permissions by Role”.
 |
Permissions Dialog Showing Permissions by User |
6. Click Apply to save your changes. If you toggle between user and role permissions, you must click Apply first to save any changes you made.
7. Click OK to save your changes and close the permissions dialog when you are finished.
You can open several permissions dialogs for different resources or folders at the same time, as well as navigate the repository. This helps when trying to set permissions uniformly across several folders or organizations.
 | There are two special cases when setting permissions: •If a resource inherits a permission, for example Read-Only, you cannot set the permission to the same value, at least not directly. You need to temporarily change the permission level on the parent folder, then set the explicit permission, then set the parent folder’s permission back to the original value. When a resource and its parent folder have been set to the same permission in this way, the permission dialog still shows the asterisk as if the permission were inherited. But when the parent is later given a different permission, for example Read-Write, the resource retains its explicit Read-Only permission instead of inheriting Read-Write. •To reset the permission level so that it once more inherits from its parent folder, select a different permissions level and click Apply, then select the permission with the asterisk and click Apply again. |
Testing User Permissions
Once you have configured users, roles, and permissions, Jaspersoft 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.
Select the user’s organization, then browse or search for the user whose permissions you are testing.
In the Users panel, select the user.
In the Properties panel, click Login as User.
The selected user’s Home page appears. The login information in the upper-right corner shows that you are logged in as that user.
6. In the repository, browse or search for the folders and resources to test.
7. Verify that JasperReports Server displays the expected folders and resources. Make a note of any objects that should be displayed but are not, and any objects that should be hidden but are displayed.
8.When you have verified the user’s permissions, click Log Out
...
Your own Home page appears.
9. To change the user’s permissions, edit the permissions in the repository and modify the user or role definitions.
10.
...
Continue testing until the user’s permissions are satisfactory.
11.
...
Repeat these steps with several representative users to ensure that your access control is properly configured. An access control configuration that hasn’t been tested doesn’t secure your data adequately.