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.
Tip
For information about row-level
security in SAS Visual Analytics, see
SAS Visual Analytics: Administration Guide.
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 Fine-Grained Controls for Data in 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.