This documentation corresponds to a historical version of Yellowfin

Access the latest release, or view a list of available versions of the documentation.

Skip to end of metadata
Go to start of metadata


Security of your Public information is critical. When deploying Yellowfin an analysis of the security needs of your business should be undertaken. Yellowfin has a number of security features that you can use to ensure the security of your Public information. These can be applied is a mix of ways depending upon the level of security that you require.

This section will cover off the how you should approach your security design and once this has been completed the options that you have for implementing that design.

Security Framework

This section describes the security framework available to you through Yellowfin. It has been set out so that the highest level security features are described first. For instance Access Roles are the highest and easiest to administer form of security whilst column level security is the most granular and by default the most complex to administer over a large user base deployment.

Access Roles and Functions

Yellowfin user management is designed around the concept of user roles. This means that multiple users share a commonly defined role for access to the application. Individual users do not have a unique security profile.
A role is a collection of available security functions. Each user will have a role associated with them. As the Yellowfin report writers you can either:

  1. Change a person’s role – and thus the type of access they have to the application or
  2. Change a role definition by adding or removing functions and thereby updating all users’ access to the system that share that role.

When a user is logged in the system checks that they are still registered in the application and if so what role they should have. Based on the role access the users interface will be dynamically built – only showing them links and functions that their role has access to.

For Example – if a user’s role does not have access to the dashboard when they login they will be taken to the report list page. A user with dashboard will be taken in to the dashboard page.

When to use

Use if you wish to limit access to certain functions – such as the ability to write reports

When not to use

Roles cannot be used effectively to limit access to information and data.


Easy to maintain for all users.


Limit the number of roles created at your organization. By increasing the number of roles the level of effort required to manage access increases. Generally only permit a single role per user. Although Yellowfin does support multiple roles it can lead to confusion in a business user.

Report Categories

All reports are managed through a similar security and categorisation infrastructure which is managed through the configuration Content Access function.
The security of your reports is managed at the category and subcategory level, not at the individual item level. The purpose of this is to simplify the creation of reports in the system.

For Example - rather than having to specify who is allow to see a specific reports each time you create a new report the security for the report is inherited from the subcategory of the item that is created.

When to use

Use categories to create meaningful business groupings for reports.
If your views are ‘write’ secured then providing access securities to categories allows a user to publish sensitive reports into secure categories for wider but secure read only distribution.

When not to use

Category security is meaningless if users can write reports against a specific view (i.e. it is unsecure) but cannot see a category in which that view logically fits.
For example the Category may be HR reports and the view is a view to the HR database.
If a user can write reports and the view is not secure then whether there is security on the category is largely irrelevant since the user will have access to the base data through report builder.
If all your sensitive views have READ level access defined – applying security to your categories is not required.


Category Security is excellent for locking read only users out of specific subject domains.


Create Subject domains that are intuitive for users to understand.
For example Executive HR – this category can then be made exclusively available to Senior Management for HR reports.
Users publishing reports into categories must be aware of the security of these folders.

Source System Access Management

When setting up a source system in Yellowfin you can define which users have the rights to create views against the source as well as write SQL queries against the source.

The general rule for source system security is that it is used for controlling Yellowfin report writers that wish to create views against the source. It is through this process that a user could write reports against the source system and thereby gain unauthorized access to data.

For Example - if the HR system is to be setup as the source system any user with View Definition access will be able to view all tables including payroll data if the source is unsecure. By securing the source to only HR view builders, only those authorized users will be able to define and manage the HR related views.

When to use

Use if you have multiple view administrators – each of whom require access to specific source databases only.
Use if some users have free hand SQL access to write reports and the data in the data source is sensitive.

When not to use

Do not set security on the source in an attempt to limit access to drag and drop report writer users.


It is easy to maintain for a select number of users.


Limit the number of users that have administration access to views. Especially if they wish to edit the same source system.
Multiple administrators can lead to contention issues when managing views.

Note: If there is only 1 Yellowfin report writers of your Yellowfin deployment, and no additional users writing SQL reports then you may consider leaving your source systems unsecure

View Access Management

The main form of security for users creating reports and having access to views which allow them to write any report is through the VIEW security.
When a report is written or edited a user must connect to the view record to determine what fields are available to them. At this stage security check is made to determine if the view that is being accessed is secure, and if so, does the user have the authority to access it.

The security on your view is the most rigorous in terms of managing access to the data that is stored in it. Not only can you control edit access but you can also control which users are permitted to read reports created from the specified view.

For Example - the Finance view is created. Only the finance department is permitted to write finance view reports. In this case the view would be defined as secure and the finance users would be added into the access list with edit access.

When to use

Use if you wish to limit users that have access to the report writing function using the specified view.
Use if you wish to be specific in defining which users can read reports created by a specified view but are not permitted to write reports.

When not to use

If reports in the view are to be written by a handful of users and then published to a wider community it is preferable not to use READ level security. Use category access for this.
For example even though the HR view contains sensitive data the HR report writers must write and distribute many reports from this view – most of which do not contain sensitive data.
Simplify security of the view by having secure categories into which the report is saved rather than managing security in both the categories and the view.
If the data contained in the view is not sensitive then do not apply security to it.


Easy to maintain for EDIT level security – can become complicated if using READ level security in conjunction with category security.


If the view is sensitive determine who the users writing reports against the view are and for whom they are writing reports. Use this to determine the best security strategy for the view. If the reports are for a wide distribution view security for read access might not be appropriate.

Column Access and Restrictions

In some cases a view might be created that is designed for general use but some columns within that view are highly sensitive. For example the salary column in the human resources view holds data that is not for general consumption.

In this case you have two options.

  1. Create a copy of the view and exclude the salary column from this instance. Save the view with a new name to indicate that the view is free of sensitive data.
  2. Alternatively Yellowfin provides you with the opportunity to define the columns as restricted columns. Once this has been done an additional layer of security needs to be defined, which allows certain users access to the restricted columns of the selected view.
    Note: security to restricted columns is globally defined. You cannot specify different users for separate restricted columns within the view.
    Only users with restricted access will be able to see the item when creating reports. In addition when a report is run only users with the access level will be able to see the column on the report.

When to use

Use if you wish to create a general view available to many users but restrict access to sensitive data to only a few users.

When not to use

Do not use if the view in general and the columns all have the same users that can access them.


Can be used to secure specific columns within a view.


This is a difficult security option to maintain from an administration point of view. Consider alternatives first.
Only users with access to the view will be able to have column level access.

Access / Value Based Filters

In some cases a view might be created that is designed for general use but you only wish report consumers to access data from the view that is relevant for their position in the organisation – such as cost centre manager.

In this case you would create an Access or Value based filter.

This is achieved by updating the source connection wizard to specify the available filters – such as cost centre and your users’ relationship to that source.

You then specify the specific columns on the view that related to that source filter – e.g. you must indicate which column in the view is the cost centre column.

When writing a report you would specify that the cost centre filter must be used as the access filter. In this case the cost centre that the report reader owns will be passed in as a filter on the query.

Only users with access filters defined will be able to see the data in their reports.

When to use

Use if you wish to create a general view available to many users but restrict access to data based on a users relationship to the data – e.g. cost centre managers.
This mechanism is very good for creating Privatised reports. By using value based filters you can create a single report which is distributes to many users. Each user will however, only see their specific / Privatised data.

When not to use

Do not use if the view in general and the columns all have the same users that can access them.


Can be used to secure data within a view to only display relevant data.


This is an easy option to maintain from an administration point of view.
This mechanism allows you to provide access to all data within a view to all your users with the security of knowing that they will only see their specific data.

Introducing the security analysis process

Before deploying Yellowfin to all your users you should determine the security management profiles that you wish to deploy.

The following sections give an overview of how you should approach the security of your Yellowfin application and the access of users to your business critical information.

Security design methodology

The security design methodology described in this guide consists of one planning stage, and two implementation phases:

  1. Analysis of business needs and planning the security solution
  2. Designing the security framework
  3. Implementing your security framework

Each implementation phase is based on an assumption that you have completed an initial planning phase. The planning phase can be done without using administrator, and is the decisive phase for the success or failure of your security. A poorly planned security framework that is not based on a study of your business needs will be difficult to maintain and may enable unauthorized access to sensitive data.
Each of these phases is described as follows:

  1. Plan the your security framework before you start using Administrator
    Before starting the first phase, you should spend time understanding your businesses security requirements and how they related to the data that will be exposed to the business through Yellowfin.
    You must analyse the security need of the target audience for each data source and view to be implemented. The structures that you use to manage security should be based on a clearly defined user need to access the data contained in those tables and columns and stay consistent with the overall security strategy of your business.
  2. Designing the security framework
    You create a security framework by understanding the needs of your users. You have choices to limit users to be report consumers only, limit access to database views, or limit the ability for users to publish reports to the Public repository.
  3. Implementing your Security Framework
    Create the user roles, groups, report categories, and provide access to date sources and views to ensure your security requirements are met. Test these requirements against a sub set of users that have various levels of access.

The table below outlines the major phases in a typical view development cycle:

Development phase



Identify the target data source and become familiar with its structure.
Know what data is contained within each table of each of the target databases.
Understand the joins.
Identify the cardinality.
Know what is possible.


Identify the user population and how it is structured; for example is the user group structured by department or by task.
Identify what information the users need.
Identify what standard reports they require.
Familiarise yourself with their business terminology so that you can name items sensibly.
Plan Identify a project strategy. For example, how many views should be created and which ones should have the capacity to be linked and to what level.


Implement your physical view SQL on the target database
Build the Yellowfin view using Administrator. This manual covers this part of the view development cycle, the actual use of the tool.
Test frequently during the build process for validity and reliability of inferred SQL.


Form a small group of users, preferably power users who have some knowledge of what information they expect to get from the view.
Pre-Release the view to these users by adding them the access security list for the view.
Ask the users to perform thorough tests simulating live usage of the view(s).


Change access security of the view so that it is available to the target user base.


Update and maintain the view as the data sources and user requirements change and grow.

Analysis Approach

The following questions and responses may assist you to define your security framework and strategy.

Do all my users need report writing access?

If no then use your reader role to only allow users with read access to the system

Is the data in my source systems sensitive?

If yes then you will need to apply security to your data source. This will stop unauthorized access to SQL report writers and users that have admin access to the product.

View Security – Is data in my view sensitive. Can all report writers have access to the data contained in it?

If some report writers do not have access to data in the view then view security is required. The security will stop unauthorized reports being written.

The majority of the view is not sensitive but only 1 or 2 columns are.

Define view columns as secure.

If publishing Public reports from the same view will some contain sensitive data and other reports not. For example an HR report containing salaries could be written from the same view as an HR report containing Headcount

If some users should be restricted from the salary data you should create two categories for report saving – one for general access which is unsecure and one for secure access.
This assumes that people with report writing access do not have EDIT access to the view – if they do then they could edit a report and add the sensitive data.

Will I reporting from source systems with completely different subject areas?

Best to set up diff categories

  • No labels