We are ready to start building a security model. We have folders and reports. Moreover, we have a list of users. Let's create users:
bi_developer
, bi_architect
sales_australia
, sales_europe
, sales_canada
, sales_us
product_analyst
finance_analyst
All new users belong to the Everyone group, in other words, they have the Normal Users security role. In other words, they haven't any access. If you want to try to connect using a new user, you will get this message:
The next step is to create groups in order to divide users by their departments. Usually, we should start from groups and then we can create a new user inside of a group. Sometimes a user can belong to several groups. Let's create groups for business departments. According to user access requirements, we will create a Sales group under the MicroStrategy Web Reporter group and Product and Finance groups will be created under the MicroStrategy Web Professional group.
In order to understand what privileges have been granted to a particular group in MicroStrategy, we could click on group and choose Edit | Project Access. As a result, we will see a list of privileges. Let's create the groups and add users to them:
finance_analyst
:
product_analyst
.bi_architect
and bi_developer
users to MicroStrategy Desktop Designers group in order to get access to Developer and Architect.As a result, all our users have access to the MasteringBI and Enterprise Manager projects, all folders and reports. Moreover, BI users have access to MicroStrategy Developer and Architect. In order to finish security, we should change the security of objects, in order to show folders and reports according to user access recommendations as well as restrict data access to the sales team according to their geographical location. In addition, we should hide the Enterprise Manager project from business users.
All our users are members of the Everyone group, and as a result they have the Normal Users security role that allows them to see all projects.
In order to hide a project, we should right-click on the project name | Project Configuration | Project Access and delete everyone from Selected members:
As a result, we hide the project from all users, even BI users. In order to return the Enterprise Manager project to BI users, we should create a new security role, for example, BI developers, and assign to it all privileges. As a result, we can choose our new role and select members - users or groups. Now we can check in MicroStrategy Web that business users can see only the MasteringBI project, and BI users can see the MasteringBI and Enterprise Manager projects.
The next step is to set up security for the object in order to make department folders visible only for their users. Only BI users are able to see all folders. Therefore, we will change security only for business users.
We have two strategies:
In our case, it is better to deny everything in the Shared Reports folder and then add access for a specific group to a specific folder. Let's update access on the Shared Reports folder in order to show it for BI users with content, and hide content from business users:
We deleted the Everyone group and Guest, but added groups with our users. For BI developers, we made Full Control access, and for business users, we chose Denied All in order to hide all folders and later to give access only to specific folders. Moreover, we applied changes to all children. We marked the sub options in order to apply changes for all objects in all folders. If we check the result of this change, we figure out that users can see folders but can't see reports. This isn't the desired result. However, we can quickly adjust it. For example, in order to leave the Finance folder for finance users we should perform the following steps:
As a result, we provided the required security access to our MicroStrategy platform. This was one of the examples of how to build security using flexible security functionality. In addition, we should take into consideration that users should have view access on public objects such as filters, consolidations, and so on, as well as schema objects. The last thing that we should implement is raw security in order to separate access for sales managers according to their location.
Let's create security filters for our sales managers. We created one user per region, but it is better to create one subgroup per region in order to apply a security filter to this group.
Let's create a security filter for users sales_canada
:
sales_canada
.Canada
and save this filter. Moreover, it is possible to add multiple filters and build complex filters.
In order to check how a security filter works, we should log in as a sales_canada
user and run an Orders by Country report:
If we are able to check the SQL definition, we will see an additional condition under WHERE
.
Despite the fact that the security filter will be applied globally for all reports that will be run by this user, it has one exception - the Freeform SQL (FFSQL) report. In addition, the report should have attributes that are used in security filters. In the Finance folder we have one more report - Sales by Country, that is, a FFSQL report. Let's add a security filter to this report by modifying the SQL definition:
Sales by Country
. WHERE a12.englishcountryregionname is not null
We should add this condition because the security filter will be applied as an additional condition only for users who have this right. As a result, we can leave just the security filter, because if the security filter isn't applied, the report will return an error message.
Country Region Name
in Object Browser and click on it. Choose ID
as the form and type as the following string: and a12.englishcountryregionname
As a result, we will apply a security filter for the report:
If we run the report in Web, we will get only Canada as a result.