MicroStrategy Access and Privilege Control by Project
From the time I last blogged and today, I have seen excellent growth in the number of MicroStrategy implementations. Many enterprises (regardless of size) have started using MicroStrategy for Business Intelligence practice. I have helped few teams to get started with MicroStrategy. One most common questions most clients had was around project security.
I would like to describe a MicroStrategy Access & Privilege Control Model which might work for most clients. The goal is to address the following:
- Define access by user and by project.
- Control who should see which BI application(s).
Define Privileges by user and user group.
Control who should do what within the application. Example, User A can run a report or create a report, where as User B should only be able to run a report.
Different privileges across multiple projects for a single user.
Control privileges by application. Example, person A can be an architect on Project 1 and the same person can be a developer on Project 2.
Define access by folder and user groups within a single project.
Control accesses by folder within the same application. Example, User A can see all the folders – “Financial”, “Operational”, etc where as User B can only see the folder “Operational”.
The above mentioned security can be implemented in numerous ways. The solution proposed below is one of the easiest and robust model.
Default Access: Every new project created in MicroStrategy will be available to the everyone group by default. The very first step is to make this unavailable to the “everyone” group.
Note: For explanatory purposes, the name of the project will be “Nalgan BI”.
Default Settings
Modified Settings
This setting confirms that any new user added to MicroStrategy environment will not have access to this project, by default.
Primary User Group: A new MicroStrategy user group (“Nalgan BI Web Users”) to be created with base privileges (Ex: Web Reporter Privileges) and this user group will have access to this project ONLY. This could be defined as the primary user group for the project “Nalgan BI”. Any user within the group will have access to Nalgan BI project and will only be able to run a report via web (Note: this depends on the privileges assigned to the group).
User Group Creation – Nalgan BI Web Users
Developer /Architect Groups: New user groups to be created under the primary user group – “Nalgan BI Power Web Users”, “Nalgan BI Developers”, “Nalgan BI Architects”.
As the name states, each of the new child groups will carry additional privileges like advanced web users, developers and architects respectively. Similar to the parent group, access will be restricted to this project only.
Department/Business Groups: New user groups to be created under the primary user group – “Nalgan BI Sales” & “Nalgan BI HR” (can be created as needed). These groups will NOT have any additional privileges and will inherit privileges from the parent group (Nalgan BI Web Users.
User Groups:
Developer/Architect Groups will control the privileges for a user while Department/Business Groups can be used to control user access by folders/reports.
If all the projects have similar groups designed, a user can be an architect in Project 1 and can be a developer in Project 2 OR a user can only have web access for Project 1 and can have desktop access for Project 2.
Similarly, if there are multiple folders in a project, access can be controlled by Department Groups. User in Sales group can have access to Folder 1 OR users in HR group can have access to Folder 2 and user outside the Department groups can have access to all the folders.
This model can be tweaked based on the number of users and access controls in your environment.
Note: The model described above is to restrict accesses and privileges. NO DATA restriction is applied. Data restrictions can be applied used Security Filters or Table Driver Security depending on client needs
