Introduction to BI Row-Level Permissions

Row-level permissions provide an additional refinement of control beyond setting permissions on libraries, tables, and columns. You use row-level permissions to define access to data at a more granular level, specifying who can access particular rows within a table.

BI row-level permissions filter SAS data sets and third-party relational tables when those data sources are accessed through a SAS Information Map. The initials BI indicate that this is a business intelligence feature. BI row-level permissions are defined in information maps, mediated and enforced by SAS Intelligent Query Services, and surfaced when reports are viewed in applications such as SAS Web Report Studio. BI row-level permissions are based on filters and rely on target data that is modeled to work with those filters.

BI row-level permissions offer the following advantages:

You can design and construct row-level filters by using a standard graphical user interface (GUI) within SAS Information Map Studio.
You can assign row-level filters to specific identities by using the standard authorization GUI for the SAS Intelligence Platform from within SAS Information Map Studio.
This feature is integrated with other SAS Intelligence Platform administrative functions. BI row-level permissions can be assigned to existing metadata identities, stored in the metadata repository, and evaluated by the authorization facility of the SAS Metadata Server.
This feature is practical for use with large, dimensionally modeled data marts. BI row-level permissions can limit access to data within fact tables without incurring the performance cost of directly filtering those tables. This is accomplished by ensuring that access to a fact table is always subject to an inner join with a filtered dimension (the filtering criteria is usually some type of identity information).
This feature provides flexibility in several ways:
- BI row-level permissions work with SAS data sets and third-party relational databases.
- BI row-level permissions do not require a specific data model.
- BI row-level permissions can be used with dynamically generated filters. This enables you to make user-specific access distinctions without defining a separate filter for each person.
This feature enables you to define granular access to third-party data without requiring you to maintain individual user accounts within those database systems.

If you want to use BI row-level permissions to implement row-level security, it is essential to understand the following points:

Although BI row-level permissions provide filtering whenever SAS data sets or third-party relational data are accessed through an information map, comprehensive security that incorporates this filtering requires a specific, high-security configuration of SAS Web Report Studio and appropriate coarse-grained operating system or DBMS protections. See Secure Environment for BI Row-Level Permissions.

CAUTION:

BI row-level permissions are defined within information maps, so these constraints do not provide comprehensive security for the underlying data sources. A user who accesses the data directly is not subject to the filters that are defined within information maps.
Although BI row-level permissions offer many advantages for Web-based reporting, not all SAS clients require that users go through information maps in order to access data. If you need row-level security for clients such as SAS Enterprise Guide, you must use access controls in the data source layer. For example, the SAS Scalable Performance Data Server enables you to define database views that filter rows based on the user ID of the connecting client (this functionality is provided by the @SPDSUSR system variable). Some third-party relational data sources can enforce row-level controls for the data that they store.

Tip
For information about other implementations of fine-grained controls, see the “Authorization Model” chapter in the SAS Intelligence Platform: Security Administration Guide.
Only dynamically generated reports display data based on the access that is defined for the requesting user. Static reports display data based on the access that is defined for the user ID that was used to generate the report. See Batch Reporting Considerations.