Thursday, February 28, 2013

[MSTG] Security Model



MicroStrategy Security Model


The MicroStrategy security model techniques control the following aspects of your BI implementation

             1.Access to the data coming from the database
             2.Access to the functionality
             3.Access to meatadata objects
 
MicroStrategy provides the following security features to implement access control to database data

Connection mapping

Pass-through execution

Security filters


Connection Mapping : By default all users in a microstrategy project use the same database connection(DSN) and database login when connecting to the database,which is defined by the database instance you assigned to the project.This means that all users have the same security level on the database side No Connection Mapping-Different MicroStategy 

Requests Appear as coming from the Same Entity

You use connection mapping to differentiate MicroStategy users from each other at the datawarehouse level or if you need to direct them to separete data warehouses.
Connection mapping is not required.

YOu create it and assign it to users or groups only if your environment can benefit from it.

Connection mapping enables you to leverage existing security views defined in the data warehouse when using MicroStategy.Consider the following scenario as an

Example:
Connection mapping also enables you to map users to different warehouses in a single project.

 
Pass through Execution
 
Pass through execution is an alternative to the connection mapping method.with pass through execution,you can link a MicroStrategy user to a database user.Every time the MicroStrategy user requests an execution against the warehouse,the database user credentials linked to him are applied

 
Security Filters
 
A security filter is a filter object that you assign to users or groups to restrict the result set when they execute reports or browse elements.security filters enable you to control,at the MicroStrategy level,what warehouse data users can see.The criteria specified by the security filter is added to the WHERE clause of every SQL pass,for all the reports the user executes.
Ex:Two regional managers have each their own security filters,according to the regions that they manage-one with Northeast and the other with Southeast.when these two regional managers run the same report,they may get different results 


Report Executed by a User without Security Filter

The user without a security filter can see all the regions avaliable in the warehouse,since there are no restrictions in the SQL clause.


Report Executed by a User with Security Filter = Northeast

The user with a security filter on the Northeast region can only see data for this specific region.The WHERE clause on the SQL impose this restriction

 
Controlling the Access to Functionality
 
We can also control the access to application functionality,such as the ability to read,modify or delete an object or the ability to create reports,use OLAP services,log in to MicroStategy Web and so forth.The microstategy system provides a rich set of security settings to enable you to control the users' access to the functionality:

privileges-Define the actions the user can perform

Security roles-Define sets of privileges

Permissions-Control access to objects

 
Privileges—Defining Actions Users Can Perform :
 
Privileges determine whether a user or group can perform a specific function,such as creating a report,viewing report SQL or using the administration monitors.You can grant users or groups the privileges you want them to have.Privileges can be assigned to users and groups directly or through security roles.

The difference is the Privileges assigned directly to users and groups grant functionality across all the projects in the project source

Privileges assigned through security roles grant functionality just within a specific project

Everyone,public/guest,Third Party Users,LDAP groups:No privileges

Predefined product-based groups:Privileges associated with their corresponding licenses

 
Security Roles :
 
A security role enables you to assign project-specific functions to users or groups by granting them sets of privileges on a project-by-project basis.You can also use this feature to determine whether a user or group can access a specific project.
  

Predefined Security Roles

Normal Users--It has no privileges granted and it is assigned to the everyone group.

Power Users--It has privileges that are typical for users who need access to advanced functionality in the interface.It is assigned to the System Administrator group and to the Administrator user.

Project Administrators--It is a group of several security roles that contain different sets of privileges according to the administraton role they present.For specific information about each of these security roles,see the System Administration guide.

 
Permissions--Controlling Access to Objects

Permissions define the type of access users have over individual objects or folders in the system.For example in the case of a report, a user may have permission to view the report definition and execute the report,but not to modify the report definition or delete the report

Each object and folder in the system contains an Access Control List(ACL) that specifies which permissions different sets of users have on that object.You edit an object ACL using the object's Properties window.You then assign a predefined grouping of permissions or create a custom grouping.

Types of Object Permission: view,modify,full control,deny all,default,custom
In a new MicroStrategy project,the default behavior enables users to save objects only within their personal folders.Administrative users are the only ones who can save objects within the Public Folder directory.You may change this design by assigning different object permission to the folders.Folders ina new project are created with these default ACLs


Access Control List(ACL)

The Access Control List (ACL) of an object is a list of users and groups and the access permissions that each of them has for the object.When granting permissions to objects,you must specify the following elements:

User -- Defines what users and groups can access the object

Object -- Defines the object permission for the user.For example you can assign view access for some users and modify access for other users.

Children (folders only) -- Defines the object permission for the objects that belong to that folder

The Default ACL of a newly created object has the following characteristic:

   Owner = Full Control
   Other users = Children ACL of parent folder
   New folders = ACL of parent folder
   Moved objects = Retains original ACL
   Copied objects = Inherits ACL  of children ACL of parent folder


Conflicting Permissions

If a user has permissions assigned to an object and is in a group that has a different permission grouping assigned to the object,the highest level of permission is granted to the User Permission ranked from highest level down to lowest level are listed below.The permissions at the top of the list override permissions lower down the list,when both types of permissions are assigned to a user:

Denied All--Highest level permission

The permissions with the fewest restrictions

The permissions with the most restrictions(except Denied All)--Lowest level permissions

 
Access Control Lists and Report Execution
 
In MicroStrategy,two of the permissions that can be grated on an object are Use and Execute.These two permissions have the following effects when granted to user for anObject





No comments:

Post a Comment