Securing Izenda
Izenda has been integrated into a wide range of application security models in compliance heavy environments. As such, it’s important to understand that Izenda does not come with a pre-configured security model. Instead, Izenda is designed to hook into existing SSO authentication models by inheriting user metadata from your application. That metadata is essential to ensuring that Izenda can adapt to your business rules and compliance requirements.
Here are some security concepts we’ll cover:
- Require Login
- Login URL
- Current User Name
- Current User Roles
- Current User Tenant ID
- Tenant Field
- Tenant IDs and Reports
- Connection Strings
- Visible Data Sources
- Hidden Columns
- Hidden Filters
- Field Value Concealing
- Page Restriction
- Tabs
- Buttons
- Reports Path
- Default Sharing Rights
- Sharing Groups and Rights
- Category Permissions
- Overwriting Reports
- Deleting Reports
- Current User is Admin
- Timeouts
- Enforcing No Locks
- Row Limits
- Column Limits
- Apply Anti XSS to Report Output
- Show HTML As Code
- Strip Invalid Characters
- Allow Invalid Characters
- SSL
- PreExecuteReportSet
- ProcessDataSet
SSO Configuration
SSO configuration involves hooking Izenda into existing login security mechanisms and user metadata. Implementing these settings is essential to securing your application and its underlying database.
Requiring Login
When implementing SSO with Izenda, it’s important to make sure that users are required to login before they can access Business Intelligence relevant pages or report parts.
Require Login
If you’re implementing the Izenda platform with any kind of security model, it will be important to use the RequireLogin API setting in order to force users to login through your login page specified by LoginURL.
Login URL
The LoginUrl setting will work in tandem with RequireLogin, determining where users should be sent if they have not yet logged in. LoginUrl should be provided with the URL to your preferred login page.
Example:
AdHocSettings.LoginUrl = "Login.aspx";
User Metadata
Izenda provides an API for inheriting basic user metadata from an existing SSO authentication system like Active Directory, OAuth, LDAP, and more.
To better understand how one might pass variables from something like Active Directory into Izenda’s API, please see the following Wiki Article.
Current User Name
The CurrentUserName setting in the Izenda API should correlate with the appropriate unique identifier implemented within your application’s security model.
Current User Roles
Similar to CurrentUserName, CurrentUserRoles in the Izenda API should be used in correlation with your own unique identifier for user roles.
Multi-Tenancy
Izenda is designed to be integrated within a wide range of applications and security models, including multi-tenant applications. There are a number of settings and application behaviors that cater to multi-tenant environments.
Current User Tenant ID
CurrentUserTenantId should be hooked into your application’s unique identifier for tenants or customers. This setting will work in tandem with TenantColumn setting and will automatically be appended to report definitions to immediately append saved report and dashboard definitions with the tenant ID of the user.
Tenant Field
The TenantField setting in the Izenda API is looking to understand the column used within your database to store Tenant IDs and distinguish one tenant’s data from another. The TenantField setting will coordinate with CurrentUserTenantId. Izenda will use the CurrentUserTenantId as a filter against the specified TenantField to make sure Tenants in a multi-tenant database cannot see each other’s data.
Show Tenant Field
ShowTenantField is a boolean API setting that decides whether or not the TenantField, the column used to store unique tenant identifiers, should be visible to users in report designers.
Reports and Tenants
When the CurrentUserTenantId setting has been implemented, Izenda will save Report and Dashboard definitions with the CurrentUserTenantId value of the user. If the user has no tenant ID, an internal application administrator for example, only reports with no tenant owner ID will be visible to that user, but report definitions saved by this user will be visible to all tenants. This gives you the ability to generate a core report and dashboard repository that will remain available to all tenants.
However, when a user does have a tenant ID they will only be able to see reports and dashboards that are saved either with no tenant ID, or with their own tenant ID. Report security is of course still further controlled by the implementation of Sharing Groups and Roles.
Data, Feature, and Report Security
Once Izenda has inherited key end-user metadata from an existing SSO authentication model, you’ll want to create various loops of logic which use the settings we’ll explore below to define a user’s privilege to your data model, Izenda’s feature sets, as well as reports dashboards and visualizations.
Data Security
Izenda is deployed in a wide range of compliance heavy environments which require precise control over data visibility. Through the Izenda API you’ll be able to control which data sources users can access, what columns and rows they have privilege to see and more.
Switching Databases Programmatically
The first step of securing your databases with Izenda will be to implement loops of logic which will determine which connection strings users will be allowed to use. Using the concepts illustrated in the article below, you could change connection strings based on role of the current user, or based on the tenant ID of the currently logged in user. One might also see fit to generate the connection string itself dynamically.
Visible Data Sources
VisibleDataSources will look to inherit an array of strings identifying which Tables, Views, and Stored Procedures should be exposed. By default Izenda will pick up existing Tables and Views as well as the underlying database constraints, primary and foreign keys. Stored Procedures must be specifically enumerated in VisibleDataSources.
Hidden Columns
HiddenColumns will determine which columns within specified VisibleDataSources users should have access to.
Hidden Filters
HiddenFilters is a setting which allows Izenda to inject into the WHERE clause of queries against Tables and Views or into Stored Procedure Parameters for the purpose of pre-filtering a users data visibility.
Hidden Filters using Inner Query
Beyond using the HiddenFilter API setting, hidden filters can also be applied using an inner query. This can provide more precise control over the way hidden filters impact a query.
Field Value Concealing
In addition to being able to prevent data from being returned, through custom formatting, Izenda can also obfuscate sensitive data.
This is not a foolproof data obfuscation technique. Encrypting and obfuscating data through databases or other services is highly recommended.
Feature Security
Izenda provides a number of settings which control a user’s access to different buttons, tabs and pages. These elements will be essential to distinguishing between administrators, power users, and basic end users.
Page Restriction
Page redirects are an essential part of page level security. While certain settings in Izenda will hide buttons which take users to report designers and settings pages, only redirects will fully protect a page from unauthorized access.
Lock Viewer
The LockViewer setting will restrict the options users will have within the ReportViewer page of the Izenda platform. Specifically, it will remove the Fields and Pivots tabs as well as the ability to edit, add, or remove filters. Users can of course still interact with a report’s defined filter operators.
Example:
AdHocSettings.LockViewer = false;
Hiding Buttons and Tabs
Izenda has a wide range of settings available for hiding various buttons and tabs from users, The following FAQ will list articles for a number of these settings.
Report Security
Report security is controlled by a number of Izenda settings which dictate things like sharing groups, rights, repository location and more. It is essential to implement report security settings in order to ensure that users are only getting access to the appropriate reports and dashboards.
Reports Path
ReportsPath is a setting which will allow you to control which report repository users should connect to. This setting should be implemented whenever you want to store different sets of reports and dashboards in entirely different locations.
Default Sharing Rights
DefaultSharingRights will control the default sharing rights of reports and dashboards.
Sharing Groups
ShareWithValues will determine which groups of roles users will be able to share reports and dashboards with. This setting will coordinate with the users CurrentUserRoles.
Sharing Roles
Sharing roles will control precisely what level of permission users will have to reports and dashboards that they have access to.
Allow Create New Category
AllowCreateNewCategory is a boolean setting which would decide whether or not a user is allowed to create new categories for report storage.
Hidden Categories
HiddenCategories is a setting which would take a list of string values which would correspond to report categories users should not be allowed to see.
It’s important to note this would not prevent users from opening the report through a direct URL, it would simply hide the category from their report list.
Allow Overwriting Reports
AllowOverwritingReports is a boolean setting which would decide whether or not a user is allowed to save over an existing report definition. This will remove the Save button from user interfaces and leave Save As available.
Allow Deleting Reports
AllowDeletingReports is a boolean setting which would determine whether or not a user is allowed to delete reports. This would hide delete buttons from the report list.
Current User Is Admin
CurrentUserIsAdmin is a boolean setting which would would allow a user to see all existing reports with full permission. If that user has a CurrenUserTenantID value, they will only have full permission to reports that share the same tenant identifier.
Application Stability, Security, and Overrides
Beyond SSO authentication and role-based permissions, Izenda also provides settings from controlling elements like database performance impact, web application security, and a series of programmatic overrides.
Query Limits
Izenda provides a number of settings which would affect the queries that Izenda executes on a user’s behalf. Implementing the following settings can help reduce the performance impact a user might have on connected databases.
Timeouts
Implementing timeout settings can help to make sure users don’t execute long running queries which could negatively affect database performance.
Use No Locks
UseNoLocks is a boolean setting which would decide whether or not queries Izenda executes will include a NOLOCK.
Example:
Limits
Izenda provides a number of additional settings which restrict how many rows or columns a user may be able to request within different areas of the application. The following article discusses a number of these settings.
Web Application Security
Izenda is deployed in a number highly secure environments. A key part of high security deployments is implementing a number of Izenda settings which would prevent web application vulnerabilities from being exploited.
Apply Anti-XSS To Report Output
ApplyAntiXSSToReportOutput is a boolean setting which would cause HTML customization and links not to render in report output.
Example:
Show HTML As Code
ShowHtmlAsCode is a boolean setting which would cause any HTML code present in report output to be shown as code.
Example:
AdHocSettings.ApplyAntiXssToReportOutput = true;
AdHocSettings.ShowHtmlAsCode = true;
Strip Invalid Characters
StripInvalidCharacters is a boolean setting which would remove invalid characters from report output.
Allow Invalid Characters
AllowInvalidCharacters is a boolean setting which would allow invalid characters to appear in report output.
AdHocSettings.StripInvalidCharacters = true;
AdHocSettings.AllowInvalidCharacters = true;
SSL
Izenda does not provide any special handlers for SSL. Overall the application should behave very much the same, but there are some elements that should be considered. The following article goes into greater depth on the subject of SSL.
SSL in IzendaOverrides
Beyond simply interacting with pre-built settings Izenda also provides a series of override-able methods where custom logic can be enforced.
PreExecuteReportSet
PreExecuteReportSet() is an exposed method in Izenda that allows developers to modify reports before they are executed, allowing for deep customization to Izenda’s report generation mechanisms.
PreExecuteReportSetPostProcessDataSet
ProcessDataSet() is a method exposed in Izenda that would allow developers to intercept a dataset after it is returned by the database and before it is rendered to the end user for last minute dataset modifications.
ProcessDataSetAdditional Documentation
Izenda Wiki:
