Usually, big companies choose enterprise BI solutions in order to meet all their requirements. One of the main requirements is providing security for thousands of users, because, usually, organizations have lots of various sensitive data, such as finance, marketing, inventory, and so on. For example, salary information is private information, and we should be sure that only HR people have access to this data. Another example is security rules based on geography. If a company has many branches, we should add security rules in order that every branch can see only their own information. Moreover, BI tools offer us rich functionality for creating, publishing, and sharing reports. We should be careful with types of access, because inexperienced users can change the dashboard, or even break it.
Despite the fact that there are plenty of BI tools on the market, they all use the same idea for building security models. In this chapter, we will learn about MicroStrategy security functionality and, using our example, will design and implement a security model.
This chapter will cover the following themes:
MicroStrategy offers us a very powerful and flexible mechanism of security. It gives us the power to manage our environment on a very granular level. The complexity of security depends on business requirements and our fantasy, that is, we can design and implement any security model in order to meet business requirements and we can choose several ways to do it. Before we start to create our own security model, we should be familiar with the main terms of MicroStrategy security functionality.
MicroStrategy allows us several options to manage security at the project source level:
The following diagram demonstrates an overview of MicroStrategy security functionality:
Let's look at security functionality more closely.
Usually, we create a username for every individual using their name and surname. We create a username and password. It is good practice to use one template of username. For example, if my name is Dmitry Anoshin, then my username is danoshin
. Moreover, we can set up a connection with the LDAP server of the organization in order to import users from the LDAP directory. We can even import groups from LDAP and maintenance group and users in LDAP. Besides that, we can import users and groups from file or Windows.
In order to group users, we use groups. For example, we can create groups according to organization structure, and assign privileges and object access to many users at once. In other words, they make our life easier.
There are two main groups in MicroStrategy:
We can access and manage groups and users using User Manager by clicking on Administration under Project Source:
By default, MicroStrategy has only two users:
We can create a new user by choosing any group and clicking New | User. We will do this later in the chapter, as well as creating new groups.
MicroStrategy security roles serves us in order that we can grant to a user or group a set of privileges so that they can access reports, create schema objects, or administer MicroStrategy.
Let's look at security roles and privileges more closely by clicking the right-hand button on any group, for example, MicroStrategy Web Reporter, and choosing Edit | Project Access:
In this window, we can see what privileges members of the Web Reporter group have by expanding Web Reporter:
It is clear that users from this group have basic access through MicroStrategy Web. According to the legend, blue marks mean privileges obtained from the user/group and green marks mean they are obtained from security roles.
There are several predefined security roles available by default:
On the preceding screen, we saw that security roles use Inherited Access. Let's look at what this means:
MicroStrategy allows us to manage data access in the data source by security filters and connection mappings.
Security filters are filter objects that can restrict data access to a user or group by adding an additional condition in a WHERE
statement. However, for Freeform reports, it doesn't work. In order to create a security filter and assign it on a project, we should right-click on Group or User | Edit | Security Filter.
We should choose the project name and click View. In order to create a new filter, we should click New and create a new filter definition using existing objects. We will do it later in this chapter:
Connection mappings allow mapping users or groups with various data source connections. It gives opportunity to use an existing security model from the data source. For example, when a user has database access, we can use his username to connect him with the database through MicroStrategy. Let's look at the following workflow, where we have a group of normal users and one VIP user:
In order to assign a connection for a group or user, we should right-click on Project Name | Project Configuration | Database Instances | Connection Mappings. Moreover, we can use connection mapping to map different databases in one project.
We can define user access to folders and objects by managing permissions. Each object in MicroStrategy has an Access Control List, which specifies permissions that users or groups have on a specific object. There are several types of Access Control List permissions existing in MicroStrategy:
The following table demonstrates object access permissions:
View |
Modify |
Full Control |
Denied All |
Default |
Custom | |
Browse |
Grant |
Grant |
Grant |
Deny |
Default | |
Read |
Grant |
Grant |
Grant |
Deny |
Default | |
Write |
Default |
Grant |
Grant |
Deny |
Default | |
Delete |
Default |
Grant |
Grant |
Deny |
Default | |
Control |
Default |
Default |
Grant |
Deny |
Default | |
Use |
Grant |
Grant |
Grant |
Deny |
Default | |
Execute |
Grant |
Grant |
Grant |
Deny |
Default |
In order to see the default permissions, we should right-click on Folder | Properties | Security. For example, here are the default permissions of the Reports folder (shared reports in Web):
Custom means that users are granted browse and read permissions. In other words, all users who are part of the Everyone group can see objects in the Reports
folder and execute them, but they cannot modify or delete them. Moreover, on the screen there are Access Control List of an object Reports
folder: