In this exercise, you will create two Security Roles and assign them to the User smith for specific Project access. Take the following steps:
- In MicroStrategy Developer, log in as administrator to the MicroStrategy Analytics Modules Project Source.
- Open the Administration Tree | Configuration Managers | Security Roles. By default you will see some roles created for the Tutorial Projects.
- Right-click | New | Security Role | Name it Basic Access | OK.
Note that no privilege has been given for this Security Role.
- Right-click | New | Security Role | Name it Admin Access | Go to the Privileges tab | Check Administration privileges set | There will be a warning message stating that there is a privilege that will bypass any restriction giving the users full control over all objects. Click OK | OK again to close the Security Role editor.
Now we will edit the Everyone Group. This is an out-of-the-box User Group of which every other Group and User is a member. It is a good practice to remove any privilege and/or Security Role from this Group since it will inherit them to every User in the Project.
- Edit the Everyone Group | Go to Group Definition | Project Access | click under the MicroStrategy Tutorial Project (Security Role Selection, where Normal Users is shown). A drop down menu will appear with available Security Roles | Select the first option, which basically blanks the Group. Repeat this process for the other two Projects (Human Resources Analysis Modules and MicroStrategy Essentials) | OK.
- Edit the User smith | Go to User Definition | Project Access | Assign to MicroStrategy Tutorial Project the Admin Access Security Role | Assign to MicroStrategy Essentials Project the Basic Access Security Role | Leave Human Resources Analysis Modules with the default Blank | OK.
The User smith will still have access to MicroStrategy Essentials since it inherits the privileges from the parent Group, while the access to Human Resources Analysis Modules is null.
You can check the privileges for the User smith and verify that all of them are grayed out under Human Resources Analysis Modules, as shown in the following screenshot:
- Log in as the User smith | Verify that, Human Resources Analysis Modules Project is not visible | Verify that in MicroStrategy Tutorial, you can edit, rename, and create new objects, whereas in MicroStrategy Essentials the access is limited (no renaming and no new object creation).
- This finalizes the exercise.
The following diagram describes how privileges affect Users, User Groups, and Projects:
When a User is member of a User Group, it will inherit the Group's privileges (union of privileges) and the resulting set will apply to all Projects. On the other hand, when a User (or User Group too) has a Security Role associated, the resulting set is applicable to a specific Project.
Special scenario: When no Security Role is applied and there is no role inherited from parent Groups such as Everyone, the role is blanked and the access to the Project in turn is completely denied.