MicroStrategy ONE

Security for Data Access

MicroStrategy has a robust security model that enables you to create users and groups, determine how they are authenticated, control what data they can see, and what functional privileges they can have. For detailed information on these features,see the System Administration Help. This section discusses the access control list (ACL) and security filters that relate to Query Builder reports only.

Access Control List

An access control list (ACL) is a list of users and groups and the access permission that each one has to objects in a MicroStrategy project. Different users may have different permissions on the same object.

When you use existing objects (including project objects) in Query Builder column mapping, the ACLs of these objects are used. However, new attributes and metrics created in Query Builder reports inherit the default ACL defined in the Project Configuration Editor. You can modify the default ACL in MicroStrategy Developer by right-clicking a project and selecting Project Configuration. In the Project Configuration window point to Project definition, then Security, and then for Set Freeform SQL and MDX objects default security select Modify. The Properties[XDA Objects] dialog box is displayed. The Permissions list has the following settings:

User

Children

Administrator

Full Control

Everyone

View

Public/Guest

View

The user who creates the new attributes and metrics in Query Builder is automatically given the Full Control permission of the new objects.

In the Properties[XDA Objects] dialog box, you can change the settings of the default ACL for different groups of users.

The changed settings will only affect the new attributes and metrics created subsequently in Query Builder reports, but not those objects created prior to the change.

Security Filters in Query Builder

In MicroStrategy, a security filter is a filter object that is used to narrow down the result set that users or groups can view when they execute reports or browse elements. Usually assigned by administrators, security filters control what warehouse data users can see within MicroStrategy.

Once a security filter is created for users or groups, it is automatically applied when those users or groups view report data or browse attribute elements. However, you must perform some additional configuration to apply security filters to a Query Builder report. You configure your Query Builder report to apply security filter qualifications by inserting and configuring a placeholder for a user or group's security filter. Placeholders of this type created in Query Builder reports are referred to as "security filter placeholders" in this section.

Query Builder works with project security filters in the following ways:

For more information on security filters in general,see the Setting Up User Security chapter in the System Administration Help.

Create Security Filter Placeholders

Security filter placeholders allow security filter qualifications to be included or ignored in the Query Builder report. You can create a Security filter placeholder as a qualification by right-clicking the Conditions pane (the middle pane on the right) and selecting Insert Security Filter. Within the Query Builder Security Filter Dialog that opens, you can create a security filter placeholder using the following options:

  • Attribute Mappings

    The Attribute Mapping pane is located on the upper right side of the Query Builder Security Filter Dialog. This is where you map attributes to columns in the query to connect to security filter qualifications. For every attribute qualification to be recognized in security filters, you need to provide the form, table, and column mapped to that attribute in the query. For example:

    Attribute

    Form

    Table

    Column

    Year

    ID

    LU_YEAR

    YEAR_ID
  • Ignored Attributes

    The Ignored Attributes pane is located below the Attribute Mapping pane in the Query Builder Security Filter Dialog. This is where you specify attributes that may be ignored by the Engine when the report is being generated, even if they appear in a security filter qualification. This option can be useful if your Query Builder report does not include attributes that are included in security filters. By ignoring attributes that are not included in the Query Builder report, it allows security filters to apply qualifications for mapped attributes without creating any security holes. For example, if you define the following:

    • Attribute Mappings: Customer is mapped to the CUSTOMER_ID column
    • Ignored Attributes: Year is chosen to be ignored because it is not part of the Query Builder report
    • Security filter definition: Year = 2026 and
      Customer = Bob

      Users with the security filter defined above are able to run the report with the Customer = Bob qualification applied to the Query Builder report. There is no security hole because the Year attribute does not appear on the report.

    You can ignore attributes that are included in the Query Builder report. However, ignoring attributes can cause security holes because all qualifications on these attributes within security filters are ignored.

  • Allow Security Filters with Top and Bottom Levels to be Evaluated Based on the Select Level of this Report

    This check box option is located in the lower part of the Query Builder Security Filter Dialog. This option explicitly defines the Select Level of the report (displayed in the line just above this option) as the true level of the data that is retrieved for the report when Top and Bottom criteria are evaluated.

    Exercise caution with this option:

    • Not selecting this option when the user has Top and Bottom levels defined will cause the report to fail.
    • Select this option only when you are sure that your query does not retrieve data outside the restriction defined by the security filters. This means that you may need to check the security filters for individual users one by one and see how each one may interact with the query.

    A security filter can be applied to a Query Builder report only if every attribute in the security filter is either mapped to a column or ignored. If only a subset of the attributes used in a security filter are either mapped to columns or ignored within the security filter placeholder, then the report will fail.

    For example, a security filter that includes qualifications on Year and Category is applied for a group of users. In the Query Builder report, Year is the only attribute that has been mapped to a column in the security filter placeholder. Since Category is not included either as an attribute mapping or an ignored attribute, the report will fail for all users with this security filter.