Row-Level Security :: SAS® Visual Analytics 7.4: Administration Guide

Introduction

Row-level security enables you to control who can access particular rows within a LASR table, and it is defined by data filter expressions. Row-level access distinctions can be based on a simple attribute (such as security clearance level) or on a more complex expression that consists of multiple criteria.

Row-level security affects access to subsets of data within a resource. To establish row-level security, you add constraints called permission conditions to explicit grants of the Read permission. Each permission condition filters a particular LASR table for a particular user or group. Each permission condition constrains an explicit grant of the Read permission so that the associated user or group can see only those rows that meet the specified condition.

When row-level security is used, there are three possible authorization decision outcomes for a user request to view data:

Grant

The requesting user can see all rows.

Conditional grant

The requesting user can see only those rows that meet the specified filtering conditions.

Denial

The requesting user cannot see any rows.

Tip

When you test conditions in a SAS Visual Analytics application (such as the explorer), refresh the data source in that application (so that the results reflect your saved changes to permission conditions). See Caching.

Permission Precedence

Here are some key points about how permission conditions are incorporated into the metadata-layer access control evaluation process:

A permission condition is applied only if it is on the setting that is closest to the requesting user. Other permission conditions that are relevant because of further-removed group memberships do not provide additional, cumulative access.
If there is an identity precedence tie between multiple groups at the highest level of identity precedence, those tied conditions are combined in a Boolean OR expression. If the identity precedence tie includes an unconditional grant, access is not limited by any conditions.

The following table provides examples:

Precedence for Permission Conditions
Principle	Scenario	Outcome and Explanation
If there are multiple permission conditions that apply to a user because of the user's group memberships, then the identity that has the highest precedence controls the outcome.	A condition on TableA limits Read permission for GroupA. Another condition on TableA limits Read permission for the SASUSERS group. The user is a member of both GroupA and SASUSERS.	The user can see only the rows that GroupA is permitted to see. GroupA has a higher level of identity precedence than SASUSERS, so the filters that are assigned to GroupA define the user's access.
If there are multiple permission conditions at the highest level of identity precedence, then any data that is allowed by any of the tied conditions is returned.	A condition on TableA limits Read permission for GroupA. Another condition on TableA limits Read permission for GroupB. The user is a first-level member of both GroupA and GroupB.	The user can see any row that is permitted for either GroupA or GroupB.

Syntax (Enhanced Editor)

Tip

To access the enhanced editor, see Set a Row-Level Permission Condition.

On the Visual tab, you can drag and drop operators and data items from the left panes.

Note: When you enter values, do not enclose them in quotation marks. The editor adds any necessary quotation marks for you.
On the Text tab, you can enter text directly. Use only those operators that are available on the Visual tab.

Note: The Text tab does not use the same syntax as the basic editor and the batch tools. For hints, select the Text tab, and then click in the window toolbar.

Syntax (Basic Editor, Batch)

Introduction

This topic is applicable to permission conditions created in the following contexts:

In SAS Visual Analytics Administrator 6.1 and earlier.
In the batch tools for metadata authorization. See Batch Tools for Metadata Authorization in the SAS Intelligence Platform: Security Administration Guide.

General Guidelines

Enclose non-numerical character values within quotation marks.
The symbol || is not supported. Instead, use the keyword OR.
Expressions with months or dates are not supported.
Do not include the WHERE keyword in any expression.

Supported Syntax

Supported Syntax
Syntax Element	Example
`AND`, `OR`, `NOT`	Toy_Type='cars' OR Toy_Type='dolls'
`IN`, `NOTIN`	Toy_Type IN ('dolls' 'cars' 'animals')
`CONTAINS`, `?`	Toy_Type CONTAINS 'cars'
`BETWEEN`, `NOT BETWEEN`	Toy_Price BETWEEN 20 AND 30
`LIKE`	Toy_Type LIKE 'dolls'
`=` , `>` , `<` , `>=` , `<=` , `<>`	Toy_Price=25
`^=` , `NE`	Toy_Price^=30

Identity-Driven Properties

The following table introduces properties that you can use to create identity-driven permission conditions. When you use these properties in a permission condition, values are dynamically substituted into the condition at run time, based on the metadata identity of each requesting user.

Identity-Driven Properties
Syntax Element	Description
`SUB::SAS.Userid`	returns the requesting user’s authenticated ID, normalized to the uppercase format USERID or USERID@DOMAIN. Here is an example for use in the batch tools: -condition "empID='SUB::SAS.Userid'"
`SUB::SAS.IdentityGroups`	returns the requesting user’s group and role memberships (direct, indirect, and implicit). The returned list contains group and role names (not display names). Here is an example for use in the batch tools: -condition "FacilityRegion IN ('SUB::SAS.IdentityGroups')"
`SUB::SAS.PersonName`	returns the requesting user’s name (as specified in the Name field on the General tab of the user’s metadata definition).
`SUB::SAS.ExternalIdentity`	returns a site-specific identifier for the requesting user. External identity values are populated by the platform’s user import macros (if you bulk load user information into metadata).

For example, if a LASR table has an empID column with values that match the user IDs with which users authenticate, you might use the condition empID='SUB::SAS.Userid'. Each affected user’s ID is substituted into the right side of the condition. In a request from the sasdemo user, the condition resolves as empID='sasdemo', so only those rows where the value in the empID column is sasdemo are returned to the sasdemo user. If you assign the condition to a group, each member’s access is restricted to those rows where the empID value matches his or her authenticated user ID. Here is an example of the full command for the use in batch tools:

sas-set-metadata-access -profile Admin "/Shared Data/LASRtableA(Table)" 
-grant sasusers:Read -condition "empID='SUB::SAS.Userid'"

Note: Two additional properties (SAS.IdentityName and SAS.IdentityGroupName) are not documented here because they are less frequently useful. See About Identity-Driven Properties in the SAS Intelligence Platform: Security Administration Guide.