Introduction

Izenda Reports adheres to the security access restrictions of your web application and page. Please make sure the authentication method and settings for the site and page Izenda Reports is on are appropriate for your organization's needs.

Since every project has its own custom security needs, we've created several methods of limiting what reports, tables, fields and data cells the user can access. Izenda Reports includes a login page and a default admin user. Most users of Izenda Reports will wish to store user access information in a database. The most common scenario follows this logic:

1. Integrator has existing/new application which uses a database for user authentication.

2. Integrator adds report information to user authentication database.

3. User logs into application and is shown only the reports which they are allowed use.

Izenda allows filtering the report on demand based upon pre-existing user information which you already have stored in a database. The settings which do this are simply to use and very powerful, allowing for a rich security model which integrates easily.

What levels of security does Izenda Reports support?

Izenda Reports provides a highly customizable security model. Typically, there are different levels of security and most integrators use multiple layers. Izenda Reports separates security on the basis of which layer it affects the most. The most common layers of security are:

• Database: the first layer of security, integrators can define in the connection string what database the user has access to.
• Data Source: the integrator can define what tables and views in the connection string the user has access to, Izenda Reports also provides a method for filtering the tables and views returned to the user.
• Report: Izenda Reports can filter the reports which are displayed to users
• Field: Izenda Reports provides methods for filtering columns which contain information which users should not see.
• Record: Izenda Reports provides methods for filtering rows which contain information which users should not see.
  

Basic Report Sharing

Izenda Reports inherits your application's security. You must supply user credentials from a login page. Whether you use sessions, database tables, or any other login and authentication method is your decision. In a multi-tenant environment, Izenda Reports will need the user name and tenant identifier. The product includes one pre-defined "Administrator" role. In order to implement any other roles, such as power users, sales or any other type, you will need to define them by using our settings to determine what kind of access permissions a role should have.

• Administrators: if a user is set as an admin, then they will be able to see all reports and overwrite even read only reports. Note: this behavior can be changed via code customization.
• All other users: if the user name is set, but the user is not an admin, then by default, that user will only see shared reports and their own reports. Note: this behavior can be changed via code customization, since all settings can be set on a per-use basis.

If you simply browse to Izenda Reports without requiring a login page, the default user is set to DefaultAdministrator, this user has admin privileges and will be able to see and change all other users' reports. You can use code to create any roles you wish, such as power users, or roles that can only view and export reports. Izenda Reports only needs to know which users are admins and what their name is. Since this is different for different users, it needs to be set as part of your application's login process.

Integrating Basic Report Sharing

The Izenda Reports needs to know which users are admins and what their name is. Since this is different for different users, it needs to be set as part of your application's login process.

Here is an example of setting user names and admin status:

Izenda.AdHoc.AdHocSettings.CurrentUserIsAdmin = true;
Izenda.AdHoc.AdHocSettings.CurrentUserName = "AdminBob";

Please see this code sample for an example

You will need to tell Izenda Reports that you are requiring a login page and where you are placing the page. You set these settings in the configure settings method as shown below. Only settings which will be global for all tenants should go in this method. Do not put per-user logic here.

public override void ConfigureSettings()
  {
    AdHocSettings.RequireLogin = true;
    AdHocSettings.LoginUrl = "Login.aspx";
  }

Report Storage Integration

Izenda Reports supports two storage modes: file system or database. For more information of how reports are stored and which mode would work best for you, please click here.

Database Level Security Integration

Izenda Reports can connect to a database on a per-user basis. In order to connect to multiple data sources, you must create a view which draws information from those data sources. Izenda Reports can then connect to the database which contains the view and stream data in to create a report. Switching database is done via code. Please see this example.

Data Source Level Security Integration

Table and View Access

To limit what data sources a user can see, apply the visible tables setting. Its argument is an array of strings. Izenda recommends creating database views to simplify the user experience. Izenda Reports will only show views, if you set ViewsOnly to true. Here is an example:

//set access to which tables and views are visible
Izenda.AdHoc.AdHocSettings.VisibleTables = new string[]{ "Products", "Categories" };

Please see this code sample for more detail.

Field Level Security Integration

Field Level Access

The field level property FieldFilterRegex is a regular expression property which filters based upon the string it's given. The user would not see any fields containing the words pass, admin or pw. Please see this example.

Record Level Security Integration

Row and Cell Level Access

Izenda Reports supports the unique feature of being able to hide report data on-the-fly on a per user basis. Consider this scenario: Bill, Mary, and John are all sales people. You want to generate the same report for each of them, but with different sales territory data. With Izenda Reports, simply generate one report, give each user a link to that report and change the filter for each user to show the specific sales data.

In this example, the PreExecuteReportSet method adds hidden filters to limit data on-the-fly.

public override void PreExecuteReportSet(Izenda.AdHoc.ReportSet reportSet)
  {
    Izenda.AdHoc.Filter f = new Izenda.AdHoc.Filter("TerritoryID");
    f.Value = GetCurrentUserTerritory();
    reportSet.Filters.AddHidden(f);
  }

A more detailed example may be found here.

Custom Report Level Security Integration

To restrict access to reports on a per-user basis, implement the ListReports() method of the AdHocConfig class as shown in this example .

Continue to Multi-Tenant Security.