Security of your Public information is critical. When deploying Yello=
wfin an analysis of the security needs of your business should be undertake=
n. Yellowfin has a number of security features that you can use to ensure t=
he security of your Public information. These can be applied is a mix of wa=
ys depending upon the level of security that you require. The security feat=
ures available include:=20
This section describes the security framework available to you through Y=
ellowfin. It has been set out so that the highest level security features a=
re described first. For instance Access Roles are the highest and easiest t=
o administer form of security whilst column level security is the most gran=
ular and by default the most complex to administer over a large user base d=
eployment.
Yellowfin user management is designed around the concept of user role=
s. This means that multiple users share a commonly defined role for access =
to the application. Individual users do not have a unique security profile.=
=20
A role is a collection of available security functions. Each user will h=
ave a role associated with them. As the Yellowfin report writers you can ei=
ther:
Change a person=E2=80=99s role =E2=80=93 and thus the type of access th=
ey have to the application or
Change a role definition by adding or removing functions and thereby up=
dating all users=E2=80=99 access to the system that share that role.
When a user is logged in the system checks that they are still registere=
d in the application and if so what role they should have. Based on the rol=
e access the users interface will be dynamically built =E2=80=93 only showi=
ng them links and functions that their role has access to.
If a user=E2=80=99s role does not have access to the dashboard when they=
login they will be taken to the report list page. A user with dashboard wi=
ll be taken in to the dashboard page.
When to use
Use if you wish to limit access to certain fu=
nctions =E2=80=93 such as the ability to write reports
When not to use
Roles cannot be used effectively to limit acc=
ess to information and data.
Benefits
Easy to maintain for all users.
Tips
Limit the number of roles created at your org=
anization. By increasing the number of roles the level of effort required t=
o manage access increases. Generally only permit a single role per user. Al=
though Yellowfin does support multiple roles it can lead to confusion in a =
business user.
All content is managed through a similar security and categorisation =
infrastructure which is managed through the Content Folders.=20
The security of your reports is managed at the folder and sub folder lev=
el, not at the individual item level. The purpose of this is to simplify th=
e creation of reports in the system.
Rather than having to specify who is allow to see a specific reports eac=
h time you create a new report the security for the report is inherited fro=
m the sub folder of the item that is created.
When to use
Use folders to create meaningful business gro=
upings for reports.
If your views are =E2=80=98write=E2=80=99 secured then providing access se=
curities to folders allows a user to publish sensitive reports into secure =
folders for wider but secure read only distribution.
When not to use
Folder security is meaningless if users can w=
rite reports against a specific view (i.e. it is unsecure) but cannot see a=
folder in which that view logically fits.
For example the Folder 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 folder is largely irrelevant since the user will have ac=
cess to the base data through report builder.
If all your sensitive views have READ level access defined =E2=80=93 apply=
ing security to your folder is not required.
Benefits
Folder Security is excellent for locking read=
only users out of specific subject domains.
Tips
Create Subject domains that are intuitive for=
users to understand.
For example Executive HR =E2=80=93 this folder can then be made exclusivel=
y available to Senior Management for HR reports.
Users publishing reports into folders must be aware of the security attach=
ed.
When setting up a source system in Yellowfin you can define which use=
rs have the rights to create views against the source as well as write SQL =
queries against the source.=20
The general rule for source system security is that it is used for contr=
olling Yellowfin report writers that wish to create views against the sourc=
e. It is through this process that a user could write reports against the s=
ource system and thereby gain unauthorised access to data.
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, o=
nly those authorised users will be able to define and manage the HR related=
views.
When to use
Use if you have multiple view administrators =
=E2=80=93 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 attem=
pt to limit access to drag and drop report writer users.
Benefits
It is easy to maintain for a select number of=
users.
Tips
Limit the number of users that have administr=
ation access to views. Especially if they wish to edit the same source syst=
em.
Multiple administrators can lead to contention issues when managing views.=
Note: If th=
ere is only 1 Yellowfin report writers of your Yellowfin deployment, and no=
additional users writing SQL reports then you may consider leaving your so=
urce systems unsecure
The main form of security for users creating reports and having acces=
s to views which allow them to write any report is through the VIEW securit=
y.=20
When a report is written or edited a user must connect to the view recor=
d to determine what fields are available to them. At this stage security ch=
eck 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 acce=
ss to the data that is stored in it. Not only can you control edit access b=
ut you can also control which users are permitted to read reports created f=
rom the specified view.
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 secu=
re and the finance users would be added into the access list with edit acce=
ss.
When to use
Use if you wish to limit users that have acce=
ss to the report writing function using the specified view.
Use if you wish to be specific in defining which users can read reports cr=
eated 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 =E2=80=93 mos=
t of which do not contain sensitive data.
Simplify security of the view by having secure categories into which the r=
eport 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 secur=
ity to it.
Benefits
Easy to maintain for EDIT level security =E2=
=80=93 can become complicated if using READ level security in conjunction w=
ith category security.
Tips
If the view is sensitive determine who the us=
ers writing reports against the view are and for whom they are writing repo=
rts. 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.
In some cases a view might be created that is designed for general us=
e but some columns within that view are highly sensitive. For example the s=
alary column in the human resources view holds data that is not for general=
consumption.=20
In this case you have two options.
Create a copy of the view and exclude the salary column from this insta=
nce. Save the view with a new name to indicate that the view is free of sen=
sitive data.
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 globa=
lly defined. You cannot specify different users for separate restricted col=
umns within the view.
Only users with restricted access will be able to see the item when creati=
ng reports. When an active report is run, restricted columns will be displa=
yed to all users who have access to the report.
Use if you wish to create a general view avai=
lable to many users but restrict access to sensitive data to only a few use=
rs.
When not to use
Do not use if the view in general and the col=
umns all have the same users that can access them.
Benefits
Can be used to secure specific columns within=
a view.
Tips
This is a difficult security option to mainta=
in from an administration point of view. Consider alternatives first.
Only users with access to the view will be able to have column level acces=
s.
In some cases a view might be created that is designed for general us=
e but you only wish report consumers to access data from the view that is r=
elevant for their position in the organisation =E2=80=93 such as cost centr=
e manager. In this case you would create an Access or Value based filter.=
=20
This is achieved by updating the source connection wizard to specify the=
available filters =E2=80=93 such as cost centre and your users=E2=80=99 re=
lationship to that source. You then specify the specific columns on the vie=
w that related to that source filter =E2=80=93 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 ac=
cess filters defined will be able to see the data in their reports.
Use if you wish to create a general view avai=
lable to many users but restrict access to data based on a users relationsh=
ip to the data =E2=80=93 e.g. cost centre managers.
This mechanism is very good for creating Privatised reports. By using valu=
e based filters you can create a single report which is distributes to many=
users. Each user will however, only see their specific / Privatised data.<=
/p>
When not to use
Do not use if the view in general and the col=
umns all have the same users that can access them.
Benefits
Can be used to secure data within a view to o=
nly display relevant data.
Tips
This is an easy option to maintain from an ad=
ministration point of view.
This mechanism allows you to provide access to all data within a view to a=
ll your users with the security of knowing that they will only see their sp=
ecific data.