Access Control

Access control ensures that people using JasperReports Server can only access the data they are allowed to see. The server 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. For more information, see section Authentication Overview.

•    Authorization – Controls access to repository objects, pages, and menus based on users and roles. Described in section Authorization Overview and subsequent sections.

•    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. For more information, refer to the JasperReports Server User Guide. If you implement Jaspersoft OLAP, you can use roles to secure your data at any level of an analysis schema’s hierarchy. For more information, refer to the Jaspersoft OLAP User Guide.

Authentication Overview

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 in JasperReports Server. The server stores user definitions, including encrypted passwords, in a private database. Administrators create, modify, and delete user accounts through the administrator pages, as described in section 12.3, “Managing Users,” on page 293.

JasperReports Server 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 named ROLE_ADMINISTRATOR. A user may belong to any number of roles and receive the privileges from each of them. The server stores role definition in its private database, and administrators create, modify, and delete roles through the administrator pages, as described in section 12.4, “Managing Roles,” on page 298.

JasperReports Server relies on the open source Acegi security framework; it has many 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)

•    SiteMinder

•    Anonymous user access (disabled by default)

JasperReports Server also supports these encryption and authentication standards:

•    HTTPS, including requiring HTTPS

•    HTTP Basic

•    HTTP Digest

•    X509

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, forcing login, and/or through HTTP Basic authentication for web services, such as Jaspersoft iReport Designer and for XML/A traffic. The server can automatically synchronize with an external authentication service. The external users don’t need to be created manually in the server first. Both users and roles are created automatically in the server from their definitions in an external authentication service. For an overview of the authentication system and details about external authentication, see the External Authentication Cookbook.

Authorization Overview

With a user’s identity and roles established, JasperReports Server controls the user’s access in these ways:

Permissions

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.

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. Note that:

•    Copying does not preserve the permissions on an object. Users may copy a read-only object, paste it into a read-write folder, then edit the object. For more details, see section Moving Folders and Resources.

•    Copying and cutting (moving) actions can only be completed if the user has Read + Write + Delete access to the folder in which the object is pasted. For more details, see section Moving Folders and Resources.

•    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 only allowed if no other resources rely on them. For more details, see section Deleting Folders and Resources.

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.

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.

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, 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, such as 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

This release of JasperReports Server introduces execute-only permission to the repository. As in file systems, execute-only permission allows running reports, dashboards, and OLAP views to access a resource, but keeps the resource from appearing in the repository.

Execute-only permission applies to folders as well, keeping them from appearing in folder tree when users browse the repository, yet still allowing the resources they contain to inherit the execute-only permission. This is useful for hiding folders and resources such as data sources that only administrators and data analyst roles need to access in the repository. However, if your execute-only folder contains read-only resources, those resource are hidden when browsing folders, but can be found, either accidentally or intentionally, by using the repository search.

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.

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.

Assigning 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.

To set permissions on a folder or resource in the repository:

3.

Right-click the folder or the resource, and select Permissions... from the context menu.

The Permissions window 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 (*).

See "Permissions Window, View by User" shows the default role-based permissions on the sample Input Data Types folder. Certain roles, likely to be data analysts, can see and modify the input data types stored in this folder. 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 username, to prevent them from removing their ability to set permissions.

See "Permissions Window, Read Only Permission Assigned to a User" shows the default permissions on the folder by user. No permissions are assigned. In the default installation, all permissions are defined by role; there are no user-specific permissions.

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 setting in See "Permissions Window, View by User".

In systems with multiple organizations, the users and roles displayed include only those within the scope of the user. In the default single organization, the organization admin cannot see the permission for the system admin/superuser or for ROLE_SUPERUSER.

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:

The selected user’s Home page appears. The login information in the upper-right corner shows that you are logged in as another user.

Your Home page appears.