Authorization. SAS 9.2 Security Administration Guide

PDF

Dokument

Reklama

P A R T

Authorization

Chapter

. . . . . . . . . .

Authorization Model

Chapter

. . . . . . . . . .

Permissions on Folders

Chapter

. . . . . . . . . .

Permissions on Servers

Chapter

. . . . . . . . . .

BI Row-Level Permissions

Chapter

. . . . . . . . . .

OLAP Member-Level Permissions

109

Chapter

. . . . . . . . .

Security Report Macros

115

C H A P T E R

Authorization Model

Overview of the Metadata Authorization Model

About Metadata-Based Permissions

Granularity and Mechanics

Inheritance Paths and Identity Precedence

Use and Enforcement of Each Permission

Inheritance Paths

Permissions by Item

Permissions by Task

Authorization Decisions

Fine-Grained Controls for Data

What Are Fine-Grained Controls?

Considerations for Batch Reporting

Identity–Driven Properties

Overview

Examples

What Implementations are Available?

How are Fine-Grained Controls Assigned?

Overview of the Metadata Authorization Model

About Metadata-Based Permissions

SAS provides a metadata-based authorization layer that supplements protections from the host environment and other systems. Across authorization layers, protections are cumulative. In order to perform a task, a user must have sufficient access in all applicable layers.

CAUTION:

Some clients (such as SAS Data Integration Studio and SAS Enterprise Guide) enable power users to create and run SAS programs that access data directly, bypassing metadata layer controls.

It is important to manage physical layer access in addition to metadata layer controls. For example, use host operating system protections to limit access to any sensitive SAS data sets. See “Host Access to SAS Tables” on page 187.

CAUTION:

Not all permissions are enforced for all items.

Enforcement of permissions other than

ReadMetadata and WriteMetadata varies by item type and (for data) by the method with which a library is assigned.

52 Granularity and Mechanics

4 Chapter 5

Granularity and Mechanics

You can set permissions at these levels of granularity:

Repository-level controls function as a gateway and as a parent-of-last-resort.

Repository-level controls are managed from the Permission Pattern tab of the repository ACT. All registered users should have ReadMetadata and

WriteMetadata permissions for the foundation repository.

Resource-level controls manage access to a specific item such as a report, an information map, a stored process, a table, a column, a cube, or a folder. You can define resource-level controls individually (as explicit settings) or in patterns (by using access control templates).

Fine-grained controls affect access to subsets of data within a resource. To establish fine-grained controls, you add constraints called permission conditions to explicit grants of the Read permission.

Inheritance Paths and Identity Precedence

Permission settings are conveyed across two distinct relationship networks:

In the resource relationships network, permissions that you set on one item can affect many other items. For example, a report inherits permissions from the folder in which the report is located. This network is a simple folder tree, with these exceptions:

The root folder isn’t the ultimate parent. This folder inherits from the repository (through the permission pattern of the repository ACT).

The root folder isn’t a universal parent. Some system resources (such as application servers, identities, and ACTs) are not in the folder tree. For these items, the repository ACT is the immediate and only parent.

Inheritance within a table or cube follows the data structure. For example, table columns and cube hierarchies don’t have a folder as an immediate parent. Instead, a column inherits from its parent table and a dimension inherits from its parent cube.

In the identity relationships network, permissions that you assign to one identity can affect many other identities. For example, if you grant a group access to a report, that grant applies to everyone who is a member of the group. This relationship network is governed by a precedence order that starts with a primary

(usually individual) identity, can incorporate multiple levels of nested group memberships, and ends with implicit memberships in SASUSERS and then

PUBLIC.

Authorization Model

4 Inheritance Paths

Use and Enforcement of Each Permission

Table 5.1

Use and Enforcement of Each Permission

Permission

(Abbreviation)

ReadMetadata (RM)

Actions Affected and Limitations on Enforcement

WriteMetadata (WM)

WriteMemberMetadata

(WMM)

CheckInMetadata (CM)

Administer (A)

Read (R)

Create (C)

View an item or navigate past a folder. For example, to see an information map you need RM for that information map. To see or traverse a folder you need RM for that folder.

Edit, delete, change permissions for, or rename an item. For example, to edit a report you need WM for the report. To delete a report you need WM for the report (and WMM for the report’s parent folder). For containers other than folders (such as repositories, libraries, and schemas), WM also affects adding and deleting child items. For example, to add an item anywhere in a repository you need WM at the repository level. For folders, adding and deleting child items is controlled by WMM, not WM.

Add an item to a folder or delete an item from a folder. For example, to save a report to a folder you need WMM for the folder. To remove a report from a folder, you need

WMM for the folder (and WM for the report). To enable someone to interact with a folder’s contents but with not the folder itself, grant WMM and deny WM.

Check in and check out items in a change-managed area. Applicable only in an optional configuration for SAS Data Integration Studio.

Monitor an OLAP server. Stop, pause, resume, refresh, or quiesce a server or spawner.

For the metadata server, the ability to perform these tasks is managed by the

Metadata Server: Operation

role, not by the A permission.

Read data. For example, while you need RM for a cube in order to see that cube, you need R for the cube in order to run a query against it. Enforced for OLAP data, information maps, data that is accessed through the metadata LIBNAME engine, and dashboard objects.

Add data. For example, on a table, C controls adding rows to the table. Enforced for data that is accessed through the metadata LIBNAME engine.

Write (W)

Delete (D)

Update data. For example, on a table, W controls updating the rows in the table.

Enforced for data that is accessed through the metadata LIBNAME engine, for publishing channels, and for dashboard objects.

Delete data. For example, D on a library controls deletion of tables from the library.

Enforced for data that is accessed through the metadata LIBNAME engine and for dashboard objects.

1 A folder’s WMM settings mirror its WM settings unless the folder has explicit or ACT (green) settings of WMM. A grant (or deny) of WMM on a folder becomes an inherited grant (or deny) of WM on the items and subfolders in that folder. WMM is not inherited from one folder to another.

2 In any change-managed areas of a foundation repository, change-managed users should have CM (instead of

WM and WMM). Change management is a SAS Data Integration Studio feature.

Inheritance Paths

In the metadata layer, parent items convey their effective permissions to child items.

Children inherit the net effect of their parents’ access controls, not the access controls

54 Inheritance Paths

4 Chapter 5 themselves. The following figures depict inheritance paths in a foundation repository.

The arrows in the figure flow from parent to child. For example, a folder conveys its effective permissions to the items that it contains. The arrows in the second figure flow from child to parent, showing the same relationships from a different perspective.

Figure 5.1

Inheritance Paths (Integrated View)

Repository ACT

ACT

User, Group, Role

Application

Server

Logical

Server

Root Folder

Server

Parent Folder

Report

Stored Process

Information Map

Library

Table Column

OLAP Schema

Cube

Measure

Dimension

Level

Hierarchy

Connection

Authorization Model

4 Permissions by Item

Figure 5.2

Inheritance Paths (Separated View)

BI Content Items

Repository

ACT

Relational Data

Root

Folder

Parent

Folder

Table

Stored

Process

Report Information

Map

Column

Cube

Library

Measure

Level

OLAP Data

OLAP

Schema

Dimension

Hierarchy

System Items

User

Group

Role

ACT

Application

Server

Logical

Server

Connection

Here are some details about the preceding figures:

The depicted folder structure is arbitrary and intended only to show the security relationships between different types of items.

Not all item types are depicted. To trace inheritance for a particular item, click

Advanced

on that item’s Authorization tab. This feature is available to only unrestricted users.

The root folder represents the top of the folder tree for the foundation repository.

It corresponds to the SAS Folders node on the Folders tab in SAS Management

Console.

The root folder inherits settings from the Permission Pattern tab of the repository ACT.

Any custom repositories are represented as folders (immediate children of the foundation root folder). Although these folders inherit permissions from both the foundation root folder and the repository ACT of the custom repository, access to items within the custom repository branch should be managed from the folder side

(except for items that aren’t in the folder tree).

On the Folders tab in SAS Management Console, your My Folder is displayed directly below the root folder. This is just a shortcut for accessing your personal content area; this folder is not an immediate child of the root folder.

The figures show users, groups, and roles inheriting repository-level permissions.

The Authorization tab in a user, group, or role displays default settings that reflect special rules that prevent regular users from modifying or deleting identities. An identity’s Authorization tab can affect access to that identity’s definition. An identity’s Authorization tab has no effect on what that identity can do.

Permissions by Item

The following figure depicts common items and uses arrows to indicate items whose permission settings are most likely to need an adjustment. Here are some details about the figure:

56 Permissions by Item

4 Chapter 5

Most of the up arrows indicate a need to extend the ability to read data. In the interest of a more secure initial deployment, read access to data is not granted by default.

Each down arrow indicates a need to limit the ability to modify or delete a system item. Other system items are protected by default.

MLE refers to the metadata LIBNAME engine. The MLE items are listed to highlight the elevated permission requirements that apply when data is accessed through this engine.

In any change-managed areas in a foundation repository, change-managed users should have CheckInMetadata permission (instead of WriteMetadata or

WriteMemberMetadata). Change management is a SAS Data Integration Studio feature.

The intent of the figure is to highlight the adjustments that are most commonly needed. In general, it is preferable to set permissions on a parent (such as a folder) rather than on a specific item (such as a report).

Figure 5.3

Common Access Adjustments By Item

Legend:

Increase access to make fully available.

Reduce access to improve security.

BI Content

Folder

Information map

Report

Stored process

Publication channel

Dashboard

Data

Folder

MLE library

Other library

MLE table

Other table

OLAP schema

Cube

System

Repository

ACTs

Repository

Predefined

User-defined

Servers

Application

Logical

Server

Identities

User

Group

Role

The following tables provide item-specific instructions and tips. The purpose of the tables is to highlight special requirements for common items.

Authorization Model

4 Permissions by Item

Table 5.2

Permissions Tips: Selected Items in the Folder Tree

The root folder is the first folder on the

Folders

tab. This folder’s

Authorization

tab is an important point of control for narrowing WM. Unlike other folders, the root folder does not have the

WriteMemberMetadata permission in its permission list. This is because the root folder is a software component object, not a true folder. The root folder can contain only other folders.

Root folder

Folder

Information map

For folders, follow these guidelines:

Provide users with a clear path of grants of ReadMetadata permission to all of the content that they access. This is a navigational requirement; to navigate past a folder, you need

ReadMetadata permission for that folder.

To enable users to contribute items to a folder, grant them WriteMemberMetadata permission on that folder.

3 On a folder, grant WriteMetadata permission only to users who should be able to delete, move, or rename that folder.

Don’t assume that every permission that is listed on a folder’s for every item in that folder.

Authorization

tab is relevant

3 If you deny ReadMetadata permission on a folder, make sure that you don’t prevent the SAS

Trusted User from having that permission on all cubes and schemas within that folder. A reasonable approach is to give the SAS System Services group a grant of ReadMetadata permission on the folder. This preserves necessary access for this privileged service identity.

See Chapter 6, “Permissions on Folders,” on page 71 and “Using WriteMetadata and

WriteMemberMetadata Permissions” on page 45.

To access any data through an information map, you need Read permission on that information map.

You can manage Read permission globally or selectively. For example:

3 A broad approach is to grant Read permission to SASUSERS on the repository ACT’s

Permission Pattern

tab or on the

Authorization

tab of the top folder.

3 A narrow approach is to grant Read permission to smaller groups on specific subfolders or even specific information maps.

Report

If a user can’t run a report, check these things:

Does the user have Read permission for the underlying information map?

Does the user have Read permission for any underlying OLAP cube?

Does the user have Read permission for any underlying relational data that is accessed via the

MLE?

Does the SAS Trusted User have ReadMetadata permission for any underlying cube?

Does the account that retrieves any underlying SAS data have physical access to that data?

Is the underlying information map in a legitimate folder? See the wrs.map.accessibility.check

property in the SAS Intelligence Platform: Web Application Administration Guide.

It is especially important to manage ReadMetadata permission to pregenerated reports, because those reports contain data. Any user who views a pregenerated report sees the same data, regardless of his or her permissions to the underlying tables or cubes.

58 Permissions by Item

4 Chapter 5

Stored process

Channel

To run a stored process, you need ReadMetadata permission on the stored process. If you can see a stored process but can’t run it, you might not have the necessary grant of Read permission for the underlying data. To register a stored process, you need WriteMetadata permission for the target application server.

The method that you use to make a stored process available can affect data retrieval and security. For example, in the standard configuration, a stored process that is assigned to a workspace server and embedded in an information map retrieves SAS data under the pooled workspace server’s host identity. However, if a user opens that same stored process directly (for example, as a report in SAS

Web Report Studio), the host identity of the requesting user (or group) retrieves the data.

In a new deployment, only the SAS Administrators group can add channels, subscribers, and content.

To enable all registered users to publish content to a particular channel, navigate on the

Folders

tab to System

I Publishing I Channels and grant Write and WriteMetadata permissions to

SASUSERS on that channel’s

Authorization

tab (WM is required only if a channel has an archive persistent store).

To enable all registered users to add channels or subscribers, grant WriteMemberMetadata permission on the relevant parent folder (for example, on the System

I Publishing I Subscribers I Content

Subscribers folder). See “Using WriteMetadata and WriteMemberMetadata Permissions” on page 45.

The permissions model for dashboards and their related items (indicators, data models, and ranges) has several unique aspects. See the SAS Intelligence Platform: Web Application Administration Guide.

Dashboard

Schema

Cube

Cube component

To associate an OLAP schema with an application server, you need WriteMetadata permission for the schema and the server. To add cubes to a schema, you need WriteMetadata permission for the schema and WriteMemberMetadata permission for the target folder.

The SAS Trusted User must have ReadMetadata permission for all OLAP schemas and cubes. This access is usually granted through the SAS System Services group.

To register cubes, you need WriteMetadata permission for the OLAP schema and

WriteMemberMetadata permission for the target folder. To associate a cube with a schema, you need

WriteMetadata permission for the cube and the schema. Read permission is enforced for cubes. Grant

Read permission broadly (as described in the information map row), or add narrower grants of Read permission on folders or individual cubes.

The SAS Trusted User must have ReadMetadata permission for all OLAP schemas and cubes. This access is granted through the SAS System Services group.

To access the the

Authorization

tab for an OLAP dimension, measure, level, or hierarchy, navigate on

Plug-ins

tab under Authorization Manager

I Resource Management I By Location I

<Application Server>.

For cube components, Read permission is enforced. If you lack access to a measure that participates in a calculated measure, you can get unintended results.

There are navigational requirements for Read permission on cube components. If a user does not have

Read permission to a hierarchy, the user can’t navigate to the top levels within the hierarchy. If a user does not have Read permission to a particular level in a hierarchy, the user can’t navigate to the next level.

To associate a library with an application server, you need WriteMetadata permission for the server

(but not for the library). For a library that is accessed via the metadata LIBNAME engine (MLE), you need the Create permission in order to add tables and the Delete permission in order to delete tables.

Library

Authorization Model

4 Permissions by Item

Table

Column

To associate a table with a library, you need WriteMetadata permission for the table and the library.

For a table that is accessed via the MLE, you need Read permission in order to access data. The

Create, Delete, and Write permissions affect your ability to add, update, or delete data. You can grant these permissions broadly (as described in the information map row) or narrowly (for example, to a small group of users on a particular table’s

Authorization

tab).

To access a column’s

Authorization

tab, navigate on the

Plug-ins

tab under Authorization

Manager

I Resource Management I By Location I <Application Server>.

The MLE doesn’t support column-level access distinctions for the Read permission. Column-level access distinctions for the ReadMetadata permission are always supported.

Table 5.3

Permissions Tips: Selected Items Outside the Folder Tree

Repository

Application server

On a foundation repository, all participating users should have repository-level ReadMetadata and

WriteMetadata permissions. To verify access:

On the

Plug-ins

tab, select

Authorization Manager

I Access Control Templates and select the repository ACT. This ACT is usually named

Default ACT

and always has a blue cylinder as part of its icon .

Right-click, select

Properties

, and select the

Permission Pattern

tab.

Select the SASUSERS group. On the repository ACT for a foundation repository, SASUSERS is usually granted ReadMetadata and WriteMetadata.

Other predefined entries in this pattern provide necessary administrative and service access.

To monitor or operate servers other than the metadata server, you need the Administer permission on the server. To verify access:

On the

Plug-ins

tab, navigate to

Server Manager

and select a server.

Right-click, select

Properties

, and select the

Authorization

tab.

Select the SAS Administrators group. Verify that this group is granted ReadMetadata,

WriteMetadata, and Administer permissions.

To associate a stored process, OLAP schema, or library with an application server, you need

WriteMetadata permission for that application server. Certain service identities need ReadMetadata permission to all server definitions. See Chapter 7, “Permissions on Servers,” on page 85.

To use a logical server, you need ReadMetadata permission for at least one of that server’s connections. This is called server access security. Certain service identities need ReadMetadata permission to logical server definitions. See “Hiding Server Definitions” on page 88.

Logical server

60 Permissions by Task

4 Chapter 5

Identity

ACT

User administration capabilities enable you to create, update, and delete users, groups, and roles. You can delegate management of an identity to someone who doesn’t have user administration capabilities by adding explicit or ACT (green) grants of WriteMetadata permission on the identity’s

Authorization

tab. An identity’s

Authorization

tab has no effect on what that identity can do.

To create an ACT, you need repository-level WriteMetadata permission. Each predefined ACT is protected by settings on its

Authorization

tab. ACTs that you create aren’t automatically protected. It is important to add protections to any ACTs that you create. To protect an ACT:

On the

Plug-ins

tab, select the ACT under

Authorization Manager

I Access

Control Templates

On the ACT’s

Authorization

tab, narrow access. For example, if you explicitly deny

WriteMetadata permission to PUBLIC, only unrestricted users can modify or delete the ACT. If you also add an explicit grant for the SAS Administrators group, members of that group can also modify or delete the ACT.

Permissions by Task

The following tables show required metadata layer permissions for selected tasks.

This list explains symbols in the tables:

An asterisk (*) in a column heading indicates that an item is optional. For example, not all reports include a stored process.

MLE indicates that the Read permission is required only if data is accessed through the metadata LIBNAME engine.

MLE, OLAP indicates that the OLAP data can be also involved (the Read permission is always required for OLAP data).

Table 5.4

Working with Folders: Permissions for Selected Tasks

Task

Add a folder

Delete a folder

Rename a folder

Set folder permissions

Add an item to a folder

Delete an item from a folder

Copy/export items

Paste/import items

1 If the parent folder is the root folder

Repository

RM, WM

Parent Folder

RM, WMM

, you need RM, WM on the root folder.

Folder

RM, WM

RM, WMM

Item

RM, WM

Authorization Model

4 Permissions by Task

Table 5.5

Working with Reports: Permissions for Selected Tasks

Task

Create and save a new report

Delete a report

View or refresh a report

View a batch report

Edit or rename a report

Set report permissions

Repository

RM, WM

Parent

Folder

RM, WMM

Report

RM, WM

Stored

Process*

Information

Map*

RM, R

Data

RM, R

MLE, OLAP

RM, R

MLE, OLAP

Table 5.6

Working with Information Maps: Permissions for Selected Tasks

Task

Create and save a new information map

Delete an information map

Set information map permissions

Edit or rename an information map

Run queries in an information map

Repository

RM, WM

Parent

Folder

RM, WMM

Information

Map

Stored

Process*

RM, WM

RM, R

Data

RM, R

MLE, OLAP

RM, R

MLE, OLAP

Table 5.7

Working with Stored Processes: Permissions for Selected Tasks

Task Repository

Delete a stored process

Set stored process permissions

Run a stored process

RM, WM

Parent

Folder

RM, WMM

Application

Server

RM, WM

Stored

Process

RM, WM

Data

RM, R

MLE, OLAP

Table 5.8

Working with Publishing Channels: Permissions for Selected Tasks

Task

Add a channel or subscriber

Delete a channel or subscriber

Edit a channel or subscriber

Publish content to a channel

Repository

RM, WM

Parent Folder

RM, WMM

1 WM is required if the channel has an archive persistent store.

2 Content is published to only those subscribers for whom you have RM.

Channel

RM, WM

RM, W, WM

Subscriber

RM, WM

62 Authorization Decisions

4 Chapter 5

Table 5.9

Working with Tables: Permissions for Selected Tasks

Task

Delete a table

Set table permissions

Access table data

Repository Application

Server

RM, WM RM

RM, WM

Library

RM, WM

Parent

Folder

RM, WMM

Table

RM, WM

RM, R

MLE

Column

Table 5.10

Working with Cubes: Permissions for Selected Tasks

Task

Delete a cube

Rebuild a cube

Refresh a cube

Set cube permissions

Access cube data

Use the OLAP Server Monitor

Repository Application

Server

RM, WM RM

RM, WM

OLAP

Schema

RM, WM

Parent

Folder

RM, WMM

Cube

RM, WM

RM, R

RM, WM

RM, R

Source

Data Sets

RM, R

MLE

RM, R

MLE

RM, R

MLE

Authorization Decisions

The following figure depicts the evaluation process that determines whether a restricted user (Joe) has a particular permission for a particular item.

Authorization Model

4 Authorization Decisions

Figure 5.4

Authorization Decision Flowchart

Deny

On the item

Does Joe have an

explicit

grant or denial of this permission?

Deny

Is there an ACT whose pattern explicitly grants or denies this permission to Joe?

Several such ACTs, at least one has a denial.

Deny

Any other tie.

Deny

Grant

Several such ACTs, none have a denial.

Permission condition?

Yes

Is there a grant or denial that applies to Joe because of his

group memberships?

Consider only the explicit and ACT settings that are closest to Joe.

On the item’s immediate parent

What is Joe’s effective setting for this permission?

Grant

Tie with an explicit grant and no explicit denial.

Permission condition?

Yes

Grant

Deny

Grant

Conditional Grant

Here are some details that help you interpret the preceding figure: explicit settings

A user has an explicit setting on an item if the user is individually granted or denied a permission on the item’s Authorization tab. Explicit settings have the highest precedence. However, managing a large number of explicit settings for individual users can be cumbersome. For greater efficiency, we recommend that you set explicit permissions for groups, use ACTs, and rely on inheritance.

ACT settings

A user has an ACT setting (green) on an item if an ACT that is applied to the item has a permission pattern that explicitly grants or denies the relevant permission to the user. Each ACT adds its pattern of grants and denials to the settings for each item to which the ACT is applied. A green check box on an item’s

Authorization

tab indicates that at least one ACT is applied to that item. To determine which ACTs are applied to an item, click the Access Control

Templates

button on the item’s Authorization tab.

64 Authorization Decisions

4 Chapter 5 indirect settings (derived from group memberships)

A user has a group setting on an item if a group to which the user belongs has an explicit or ACT setting on the item. Group settings matter only if the requesting user has no relevant explicit or ACT settings on the target item.

Identity precedence determines which group settings are closest to each user. See

“Identity Precedence” on page 34.

If you directly assign a user to multiple groups (or directly assign a group to multiple groups), you can get identity precedence ties. For example, if Joe is a direct member of GroupA and GroupB, and the only settings on an item are conflicting explicit settings for those groups, both of those settings are closest to

Joe. These conflicts are resolved as follows:

Explicit settings have precedence over ACT settings.

Conflicting explicit settings result in a denial.

Conflicting ACT settings result in a denial.

indirect settings (inherited from a parent item)

Inherited settings come from a parent item (such as a folder). Inherited settings matter only if there are no relevant explicit, ACT, or group settings on the target item. When there are no relevant settings on an item, access to the item is the same as access to the item’s immediate parent. The controlling setting is usually an explicit or ACT setting that is defined somewhere in the item’s inheritance path.

If there are no explicit or ACT settings on any parent (or if the item’s only parent is the repository), the repository ACT determines the outcome. If that ACT’s pattern neither grants nor denies the permission, then the permission is denied.

Note:

If there is no repository ACT, all permissions are granted (you should always have a designated repository ACT).

Note:

If an item has more than one immediate parent, a grant from any inheritance path is sufficient to provide access. Having multiple immediate parents is not a common situation.

4 permission conditions

Permission conditions constrain explicit grants of the Read permission on OLAP dimensions (limiting access to members) or information maps (limiting access to rows). On the Authorization tab, the presence of an Edit Condition or Edit

Authorization

button indicates that a permission condition is assigned to the currently selected user or group. See Table 5.14 on page 69.

The following table summarizes the principles of the authorization decision process:

Table 5.11

Precedence Principles for Authorization

Principle

Settings on an item have priority over settings on the item’s parents.

Conflicting settings on an item are resolved by identity precedence.

In an identity precedence tie, explicit settings have priority over

ACT settings.

Example

LibraryA has an explicit denial for PUBLIC. LibraryA’s parent folder has an explicit grant for Joe.

LibraryA has an explicit denial for GroupA and an explicit grant for GroupAA. Joe is a direct member of GroupA.

GroupA is a direct member of GroupAA.

LibraryA has an ACT denial for GroupA and an explicit grant for GroupB. Joe is a direct member of both GroupA and GroupB.

Outcome

Joe can’t see

LibraryA.

Joe can’t see

LibraryA.

Joe can see

LibraryA.

Authorization Model

4 Considerations for Batch Reporting

Principle

In an identity precedence tie that isn’t resolved by the preceding row, the outcome is a denial.

A grant from any inheritance path can provide access.

Example

LibraryA has an explicit denial for GroupA and an explicit grant for GroupB. Joe is a direct member of both GroupA and GroupB.

ObjectA has no explicit or ACT settings, one immediate parent that conveys a grant, and another immediate parent that conveys a denial.

Outcome

Joe can’t see

LibraryA.

Joe can see

ObjectA.

1 The settings described in this column are the only explicit or ACT settings for ReadMetadata permission on

LibraryA (or ObjectA).

2 Having more than one immediate parent is not a common circumstance.

Fine-Grained Controls for Data

What Are Fine-Grained Controls?

Business requirements often specify that different users should see different portions, or slices, of data. In some cases, the requirement is driven by the sensitive nature of data. For example, company policy might state that each sales person should be able to access only his or her own salary information. In other cases, the requirement is intended to prevent information overload. For example, each regional sales team within a national organization might be interested in only the sales trend information for their region. Row-level access distinctions are frequently based on each user’s place in an organizational structure such as a management hierarchy or a product matrix. The visibility of data can depend on a simple, site-specific condition such as a user’s security clearance level, or on a more complex condition that consists of multiple filters.

You use fine-grained controls to specify who can access particular rows within a table or members within a cube dimension. These controls often subset data by a user characteristic such as employee ID or organizational unit. For example, a table that contains patient medical information might be protected by row-level permissions that enable each doctor to see only those rows that contain data about that doctor’s patients.

Unlike other access controls, fine-grained controls are based on filters and rely on target data that is modeled to work with those filters. When fine–grained controls are used, there are three possible authorization decision outcomes for a request to view data:

Grant

The requesting user can access all data.

Deny

Grant-withconditions

The requesting user can’t access any data.

The requesting user can access only the data that meets specified filtering conditions.

Considerations for Batch Reporting

When you use fine-grained controls, it is essential to understand that 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. For example:

Manually refreshed reports contain cached data (which can be updated by a user action in the report viewer).

66 Identity–Driven Properties

4 Chapter 5

Pre-generated reports reflect the access of the user ID that was used to generate the report. Identity-specific access distinctions are preserved for pre-generated reports only if you define a separate report job for each user ID.

Identity–Driven Properties

Overview

It is often necessary to make per-person access distinctions for the rows in a table or the members in a dimension. You can make a separate filter for each user (such as

where name="joe"

). However, if you have more than a few users, this approach quickly becomes cumbersome. The more efficient alternative is to create a dynamic filter (such as where name="&name;") that can discover and insert the correct, user-specific value into the WHERE expression each time access is requested.

To create a dynamic filter, use an identity–driven property as the value against which values in the target data are compared. This list explains how the substitution works:

Note:

This discussion is not applicable to the SPD Server, which has its own implementation of identity-based filtering.

Each identity-driven property corresponds to a characteristic (such as name, user

ID, or external identity).

Each user’s values for these characteristics (such as joe, WinXP\joe, or 607189) are stored in the metadata.

The identity-driven property is aware of the user ID with which a client authenticated and can locate information that is stored in the metadata for that user ID.

Each time it receives a request, the identity-driven property substitutes a user-specific value into the filter expression.

These are the most useful identity-driven properties:

SAS.Userid

returns an authenticated user ID, normalized to the uppercase format USERID or

USERID@DOMAIN.

SAS.ExternalIdentity

returns a site-specific value (for example, employee ID). This property is often useful because its values are likely to match user information in your data. An identity can have more than one external identity value; however, only the first value is returned. Unlike the values for other identity-driven properties, values for this property are not always populated in the metadata. See “External Identities” on page 226.

SAS.IdentityGroups

returns a list of the groups and roles that this identity belongs to (directly, indirectly, or implicitly). The list contains the group and role names, as displayed in the Name field on the General tab for each group or role.

SAS.PersonName

returns a user name, as displayed in the Name field on the user’s General tab.

These identity-driven properties are also supported:

SAS.IdentityGroupName

returns a group name, as displayed in the Name field on the group’s General tab.

If a user logs on with an ID that is stored in a login on a group definition, then the

Authorization Model

4 What Implementations are Available?

name of the group that owns that login is returned. If a user logs on with a user

ID that is not stored in the metadata, then the PUBLIC group is returned.

This property is useful only in the unusual circumstance where a user logs on with the user ID that is defined for a group login. In almost all cases, a user logs on with a user ID that is defined for an individual user definition. This property is not supported if client-side pooling is used.

SAS.IdentityName

returns a user name or group name, as displayed in the Name field on the General tab for the user or group. This property is a generalization of SAS.PersonName

and SAS.IdentityGroupName.

Note:

In certain circumstances, a connecting identity might not have a value for the identity-driven property that you are using. This can happen with the ExternalIdentity property (sometimes), the IdentityGroupName property (almost always), or the

PersonName property (rarely). When a connecting user doesn’t have a value for the property that a query uses, an empty string is returned or the query fails.

Examples

For example, to enable each user to see only his or her own salary information, you could give the PUBLIC group a filter that is based on the SAS.PersonName property.

At run time, the SAS.PersonName value that is associated with the connected user ID is substituted into the filter. In this way, the query is modified as appropriate for each requesting client.

This table contains examples of filters that are based on identity properties, showing representations of both the generic form and how each filter would be modified when executed by a user named Harry Highpoint. Harry is a member of the ETL and

Executives groups. The example assumes that the customer has an employee information table named EmpInfo which includes Name, Category, WinID, Department, and EmpID columns.

Table 5.12

Examples of Filters That Use Identity-Driven Properties

As Defined (Generic Form)

Where EmpInfo.WinID=&SAS.Userid;

Where EmpInfo.EmpID=&SAS.ExternalIdentity;

Where EmpInfo.Department IN &SAS.IdentityGroups;

Where EmpInfo.Name=&SAS.IdentityName;

Where EmpInfo.Name=&SAS.PersonName;

Where EmpInfo.Category=&SAS.IdentityGroupName;

As Executed (Resolved Form)

Where EmpInfo.WinID="HIGH@WIN"

Where EmpInfo.EmpID="123–456–789"

Where EmpInfo.Department IN

(’ETL’,’Executives’,’PUBLIC’,’SASUSERS’)

Where EmpInfo.Name="Harry Highpoint"

Where EmpInfo.Category=’ ’

1 Because the user does not log on with a user ID that is stored as part of a group definition, the user has no value for this property. This either returns an empty string (in BI row-level permissions) or causes the query to fail (in other implementations).

What Implementations are Available?

Each of these components offers an implementation of fine-grained controls:

Information Maps (BI Row-Level Permissions)

68 How are Fine-Grained Controls Assigned?

4 Chapter 5 provides filtering for SAS data sets and third-party relational data accessed through an information map. You define and assign the filters in SAS Information

Map Studio. See Chapter 8, “BI Row-Level Permissions,” on page 93.

This feature is practical for use with large, dimensionally modeled data marts.

BI row-level permissions do not require a specific data model. 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 enables you to define granular access to third-party data without requiring you to maintain individual user accounts within those database systems.

CAUTION:

Not all SAS clients require that users go through information maps in order to access data.

Comprehensive security that incorporates BI row-level permissions requires a specific, high-security configuration of SAS Web Report Studio.

SAS OLAP Server provides filtering for SAS OLAP data using MDX expressions. You define and assign the filters in SAS Management Console, SAS OLAP Cube Studio, or SAS

Data Integration Studio. See Chapter 9, “OLAP Member-Level Permissions,” on page 109.

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. The metadata-based identity driven properties are not available in this implementation. See the SAS Scalable Performance Data Server: Administrator’s

Guide.

The following table compares the implementations:

Table 5.13

Comparison of Fine-Grained Control Implementations

Implementation Secure Graphical Filter

Creation

Standard

Authorization UI

Metadata-

Aware

Identity-

Driven

OLAP member-level

SPD Server row-level

BI row-level

How are Fine-Grained Controls Assigned?

Note:

This discussion is not applicable to the SPD Server.

Fine-grained controls are assigned to users or groups on the Authorization tab of the target dimension or table. These filters are available only to constrain an explicit grant of the Read permission. These filters are incorporated into the access control evaluation process as permission conditions.

A permission condition is applied only if it is on the setting that is closest to the requesting user. Other conditions that are relevant because of further-removed group memberships don’t 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

Authorization Model

4 How are Fine-Grained Controls Assigned?

precedence tie includes an unconditional grant, access is not limited by any conditions.

The following table provides examples:

Table 5.14

Precedence for Permission Conditions

Principle

If there are multiple permission conditions that apply to a user because of the user’s group memberships, then the highest precedence identity controls the outcome.

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.

Scenario

A filter on InformationMapA limits Read permission for

GroupA.

Another filter on

InformationMapA limits Read permission for the SASUSERS group.

The user is a member of both

GroupA and SASUSERS.

A filter on DimensionA limits

Read permission for GroupA.

Another filter on DimensionA limits Read permission for

GroupB.

The user is a first level member of both GroupA and

GroupB.

Outcome and Explanation

The user can see only the rows that GroupA is permitted to see.

GroupA has higher identity precedence than SASUSERS, so the filters that are assigned to

GroupA define the user’s access.

The user can see any member that is permitted for either GroupA or

GroupB.

The following example describes the impact of identity precedence when a manager uses an information map that includes both of the following filters for a SALARY table:

A permission condition that is assigned to the SASUSERS group gives each user access to his or her own salary information.

A permission condition that is assigned to a Managers group enables each manager to see the salaries of the employees that he or she manages.

When the manager accesses the SALARY table, the filter that is assigned to the

Managers group is applied and the filter that is assigned to SASUSERS is ignored.

This is because the manager’s direct membership in the Managers group has higher identity precedence than the manager’s implicit membership in the SASUSERS group.

To avoid a situation in which managers can see their employees’ salaries but each manager can’t see his or her own salary, you can use either of these approaches:

Assign the filters to two groups that have the same identity precedence. For example, if you assign the first filter to a general purpose user-defined group

(rather than to SASUSERS), and you make each manager a direct member of that group, then managers will have an identity precedence tie between that group and the Managers group. This situation causes the two filters to be combined for members of the Managers group, enabling those users to see any row that is permitted by either filter.

Define the Managers filter in a way that encompasses all of the rows that the managers should be able to see. In other words, combine (OR together) the

SASUSERS filter and the Managers filter.

C H A P T E R

Permissions on Folders

Using Custom Folders to Manage Access

Baseline ACTs

Demonstration: Departmental and Project Separation

Variation 1: Add Subgroups, Designate Content Creators

Variation 2: Add Functional Separation

Key Points About the Baseline ACT Approach

Further Considerations for Permissions on Folders

Consolidation of ACTs

Separated Administration

End Users, Folders, and Permissions

Using Custom Folders to Manage Access

To use the metadata authorization layer to manage access to content (such as reports, data, information maps, and stored processes), create folders and set permissions so that each folder offers appropriate access. Items within each folder inherit permission settings from that folder.

Note:

If you aren’t familiar with the SAS folder structure, see the chapter "Working with SAS Folders" in the SAS Intelligence Platform: System Administration Guide.

Baseline ACTs

One approach to establishing protections on custom folders is to create a few general-use ACTs and apply one or more of those ACTs on the Authorization tab of any folder that you need to secure. To grant access back to a particular group, supplement a folder’s baseline ACT settings by adding grants on that folder’s

Authorization

tab.

The examples in this chapter use the following baseline ACTs:

Hide prevents visibility (for users who aren’t in the SAS Administrators group).

Protect

LimitData prevents updates, deletions, and contributions (by users who aren’t in the SAS Administrators group).

prevents access to data through the OLAP server, information maps, and the metadata LIBNAME engine (for all restricted users).

72 Baseline ACTs

4 Chapter 6

Each ACT’s name describes the effect of applying that ACT to an item that has no explicit or ACT (green) settings. The following tables document the permission pattern for each of these ACTs:

Table 6.1

The Hide ACT

Group

PUBLIC

SAS Administrators

SAS System Services

Permission Pattern

Denial ReadMetadata

Grant ReadMetadata

1 Gives SAS Administrators and service identities exclusive read access to metadata.

Table 6.2

The Protect ACT

Group

PUBLIC

SAS Administrators

Permission Pattern

Denial WriteMetadata, WriteMemberMetadata,

CheckInMetadata, Write, Administer

Grant WriteMetadata, WriteMemberMetadata,

CheckInMetadata, Write, Administer, ReadMetadata

1 Gives SAS Administrators exclusive write access to metadata.

Table 6.3

The LimitData ACT

Group

PUBLIC

Permission Pattern

Denial Read

1 Prevents all restricted users from accessing data (through information maps, the OLAP server, and the metadata LIBNAME engine).

Each baseline ACT reduces a particular type of access down to a minimal level. In the Hide and Protect ACTs, the grants to SAS Administrators preserve standard administrative access so that members of that group can manage all metadata (for alternatives, see “Separated Administration” on page 83). In the Hide ACT, the grant to

SAS System Services preserves necessary service access (the SAS Trusted User, who is a member of that group, reads certain metadata on behalf of all users). The LimitData

ACT is unusual in that the pattern consists of a single setting. This chapter uses this

ACT for consistency and in case at some future point you want to give a restricted user access to all data.

To create the baseline ACTs:

Log on to SAS Management Console as a registered user (anyone who has a well-formed user definition). Select the Plug-ins tab.

Expand Authorization Manager, right-click Access Control Templates, and select New Access Control Template.

On the General tab, enter the ACT name (Protect, Hide, or LimitData).

Note:

If you previously created the Protect ACT to protect server definitions, just verify that the pattern on that ACT is correct.

Permissions on Folders

4 Demonstration: Departmental and Project Separation

On the Permission Pattern tab, define the settings this ACT will provide:

a b

Click Add. In the Add Users and Groups dialog box, clear the Show Users check box. Move PUBLIC and any other participating identities (SAS

Administrators

and SAS System Services) to the Selected Identities list box. Click OK.

On the Permission Pattern tab, define explicit settings as specified in the preceding tables. Remove the automatically created grants of

ReadMetadata permission except as specified.

Note:

Make sure you are on the Permission Pattern tab and not the

Authorization

tab.

On the Authorization tab, protect the ACT that you are creating. Either apply the Protect ACT or add explicit settings that deny WriteMetadata permission to PUBLIC and grant WriteMetadata permission to the SAS Administrators group.

Note:

If the Users and Groups list box on the ACT’s Authorization tab is empty, click OK to save the ACT. Then, right-click the new ACT, select

Properties

, and select the Authorization tab again.

Click OK. Repeat until you have created all three baseline ACTs.

Demonstration: Departmental and Project Separation

This example creates a secured custom branch with mutually exclusive access for two divisions. In this example, the project level folders are for only organizational purposes

(there are no access distinctions at the project level). The following figure depicts the goals and group structure.

Figure 6.1

Demonstration: Folder and Group Structure

SAS Folders

My Folder

DemoBranch

DivisionA

Project1

Project2

DivisionB

Project1

Project2

GroupA can consume and contribute.

GroupB can consume and contribute.

PUBLIC

SASUSERS

SAS Administrators sasadm

SAS System Services sastrust

GroupA userA

GroupB userB

To set this up, complete these steps:

74 Demonstration: Departmental and Project Separation

4 Chapter 6

Log on to SAS Management Console as someone who has user administration capabilities and is a member of SAS Administrators (for example, sasadm@saspw).

Select the Plug-ins tab.

Create two temporary groups:

a b c

Right-click User Manager and select New

I Group.

On the General tab, enter the name GroupA. Click OK.

Repeat steps 2a-b to create a group named GroupB.

Create two temporary users:

4 f a b c d e

Right-click User Manager and select New

I User.

On the General tab, enter the name userA.

On the Groups and Roles tab, move GroupA to the Member of list box.

On the Accounts tab, click Create Internal Account. In the New Internal

Account dialog box, enter and confirm a simple password (for example

123456

). Click OK to save the new account.

Notice that the new account now appears at the bottom of the Accounts tab.

Click OK to save the new user.

Repeat steps 3a-e to create userB (who should be in GroupB).

Create the folder structure:

5 a b

On the Folders tab, right-click the root folder

Folder

. Create a new folder named DemoBranch.

and select New

Add subfolders under DemoBranch until it looks like the structure in the preceding display.

Protect the top of your custom branch:

a b c

Right-click DemoBranch and select Properties.

On the Authorization tab, click Access Control Templates.

In the Add and Remove Access Control Templates dialog box, move the Protect and LimitData ACTs to the Currently Using list box (you have to expand the

Foundation

node to get to the ACTs).

Note:

For instructions for creating the ACTs, see “Baseline ACTs” on page

71.

Click OK to return to the Authorization tab. Review the revised settings.

Notice that PUBLIC and SAS Administrators have some green settings

The green settings come from the ACTs that you applied.

On the DivsionA folder:

7 a b

Apply the Hide ACT.

Add GroupA to the Authorization tab and give them explicit

ReadMetadata, WriteMemberMetadata, and Read permissions.

On each project folder below DivisionA: grants of

8 a b

Apply the Protect ACT.

Give GroupA an explicit grant of the WriteMemberMetadata permission.

Repeat steps 6 and 7 for the DivisionB folders and subfolders (assigning the grants to GroupB). The following table summarizes the protections for the first four folders:

Permissions on Folders

4 Demonstration: Departmental and Project Separation

Table 6.4

Demonstration: Permission Settings

Folder

Baseline ACTs

Protections

Supplemental Grants

DemoBranch

Protect

LimitData

DivisionA

Hide GroupA: +RM, +WMM, +R

Project1

Project2

Protect

GroupA: +WMM

Test the protections:

a b

Log on as userA@saspw. On the Folders tab, notice which folders in the

DemoBranch are visible to you. Right-click each folder and notice where you can add content (where the New Folder and New Stored Process actions are available) and where you can’t.

Log on as userB@saspw and repeat the same checks.

To clean up, log on with the identity that you used in step 1. On the Plug-ins tab, delete the temporary groups and users (under User Manager). On the Folders tab, delete the DemoBranch and each user’s My Folder

Users

(under System

Here are some key points about this example:

ReadMetadata permission flows into the DemoBranch from its parent folder. In all of the examples in this chapter, the immediate parent to the DemoBranch is visible to all registered users (SASUSERS). This is a standard setting. Unless you apply the Hide ACT to the top of your custom branch, the SASUSERS grant of

ReadMetadata permission flows into your branch.

The ability to create, manage, and delete content is shut off at the top (by the

Protect ACT on the DemoBranch). This constraint flows throughout the tree

(except where you add supplemental grants of WriteMemberMetadata permission to specific functional groups on specific folders). Users don’t add content or access data in the DemoBranch, so no supplemental grants are needed on that folder.

Because you want to prevent members of GroupB from seeing the DivisionA branch, you apply the Hide ACT on that branch. You then add supplemental grants for GroupA to restore their access.

On DivisionA’s project folders, you apply the Protect ACT to override GroupA’s inherited grant of WriteMetadata permission (GroupA’s grant of

WriteMemberMetadata permission on DivisionA becomes an inherited grant of

WriteMetadata permission on the immediate children of DivisionA). This prevents members of GroupA from renaming, deleting, or changing permissions on each project folder. You then add a supplemental grant of WriteMemberMetadata permission so that members of GroupA can contribute content in the project folders.

On DivisionA’s project folders, you don’t apply the Hide ACT, because the

ReadMetadata access that flows in from the DivisionA folder is appropriate. In this example, the requirement is that all members of GroupA should be able to access content throughout the DivsionA branch.

76 Variation 1: Add Subgroups, Designate Content Creators

4 Chapter 6

Notice that it isn’t necessary to use separate folders for each type of object.

Note:

Any content contributors who register cubes must have WriteMetadata permission on the OLAP schema . By default, the schema is in the SAS Folders/

Shared Data/ SASApp - OLAP Schema

folder.

Variation 1: Add Subgroups, Designate Content Creators

This example eliminates the project folders and introduces the following requirements:

Regional employees see only content for their region.

A central group of managers see all content.

A central group of content creators creates all content.

The following figure depicts the folder and group structure.

Figure 6.2

Variation 1: Folder and Group Structure

Managers can consume.

ContentCreators can consume and contribute.

SAS Folders

My Folder

DemoBranch

DivisionA

RegionA1

RegionA2

DivisionB

RegionB1

RegionB2

PUBLIC

SASUSERS

SAS Administrators sasadm

SAS System Services

Managers sastrust

ContentCreators

RegionA1 group can consume.

RegionA2 group can consume.

RegionB1 group can consume.

RegionB2 group can consume.

GroupA

RegionA1

RegionA2

GroupB

RegionB1

RegionB2

The following table lists the protections for the first four folders:

Permissions on Folders

4 Variation 1: Add Subgroups, Designate Content Creators

Table 6.5

Variation 1a: Permission Settings

Folder Protections

Baseline ACTs Supplemental Grants

DemoBranch

Protect

LimitData

DivisionA

Hide GroupA: +RM

ContentCreators: +RM

Managers:+RM

RegionA1

Hide RegionA1: +RM, +R

ContentCreators: +RM, +R, +WMM

Managers:+RM, +R

RegionA2

Hide RegionA2: +RM, +R

ContentCreators: +RM, +R, +WMM

Managers:+RM, +R

Notice that you are repeating many of the same explicit settings on each region, and that this will be the case throughout the DemoBranch. For greater efficiency and more centralized control, create a custom ACT (called RegionLevel) that provides the supplemental grants for your content creators (RM, R, WMM) and your managers (RM,

R). Remember to protect the ACT itself as explained in step five in “Baseline ACTs” on page 71.

The following table lists the protections for the first four folders:

Table 6.6

Variation 1b: Permission Settings (use a supplemental ACT)

Folder

Baseline ACTs

Protections

Supplemental Grants

DemoBranch

Protect

LimitData

DivisionA

Hide GroupA: +RM

ContentCreators: +RM

Managers:+RM

78 Variation 1: Add Subgroups, Designate Content Creators

4 Chapter 6

Folder

RegionA1

RegionA2

Baseline ACTs

Hide

Protections

Supplemental Grants

RegionA1: +RM, +R

RegionLevel

RegionA2: +RM, +R

RegionLevel

If you decide to offer content at the division level and you want that content to be available to only managers, you might make these changes:

Create a DivisionLevel ACT with grants for Managers (RM, R) and

ContentCreators (RM, R, WMM). Apply that ACT to each division folder.

Note:

This is the same pattern that you use for the RegionLevel ACT, so you could instead simply use that ACT. In this example, you choose to create a separate ACT because you anticipate that the requirements for division-level access and region-level access might diverge in the future.

Apply the Protect ACT on each region folder (to take away the inherited grant of

WriteMetadata permission that content contributors inherit from their division-level grant of WriteMemberMetadata permission).

Note:

If you choose to not do this, members of the content creators group can delete, rename, or change permissions for the region folders.

The following table lists the protections for the first four folders:

Table 6.7

Variation 1c: Permission Settings (support division-level content)

Folder

Baseline ACTs

Protections

Supplemental Grants

DemoBranch

Protect

LimitData

DivisionA

Hide GroupA: +RM

DivisionLevel

Folder

RegionA1

RegionA2

Permissions on Folders

4 Variation 2: Add Functional Separation

Baseline ACTs

Hide

Protect

Hide

Protect

Protections

Supplemental Grants

RegionA1: +RM, +R

RegionLevel

RegionA2: +RM, +R

RegionLevel

Variation 2: Add Functional Separation

This example includes three custom groups that represent users who have specific job responsibilities (Data Admins, Map Creators, and Report Creators). Each division folder has separate subfolders for different types of content (data definitions, information maps, report definitions, and stored processes). Supplemental write access in each folder is limited to members of the appropriate functional groups as follows:

Data administrators can work in each division’s data definitions folder.

Information map creators can work in each division’s information maps folder.

Report creators can work in each division’s reports folder.

Information map creators and report creators can work in each division’s stored processes folder.

Note:

Access for these functional groups is also limited by departmental separations. For example, only DivisionA’s report creators (and SAS Administrators) can add, update, and delete items in DivisionA’s reports folder.

The following figure depicts goals and group structure.

80 Variation 2: Add Functional Separation

4 Chapter 6

Figure 6.3

Variation 2: Folder and Group Structure

Managers and

GroupA can consume.

SAS Folders

My Folder

DemoBranch

DivisionA data definitions information maps reports stored processes

DivisionB

PUBLIC

SASUSERS

SAS Administrators

GroupA’s Data Admins can contribute.

GroupA’s Map Creators can contribute.

GroupA’s Report Creators can contribute.

GroupA’s Map Creators and Report Creators can contribute.

SAS System Services sasadm

Managers sastrust

GroupA

Data Admins

Map Creators

GroupB

Report Creators

The following table lists the protections for the first six folders:

Table 6.8

Variation 2a: Permission Settings (functional separation)

Folder

Baseline ACTs

Protections

Supplemental Grants

DemoBranch

Protect

LimitData

DivisionA

Hide Managers: +RM, +R

GroupA: +RM, +R data definitions

Protect* Data Admins: +WMM information maps

Protect* Map Creators: +WMM reports

Protect* Report Creators: +WMM stored processes

Protect* Map Creators: +WMM

Report Creators: +WMM

* You don’t strictly need the Protect ACT here, because protections flow through from the

DemoBranch folder (and aren’t interrupted by any supplemental grants of WM or WMM on higher level folders). However, you do need the supplemental grants of WMM on these folders, so you might choose to also apply the Protect ACT here for clarity.

Permissions on Folders

4 Key Points About the Baseline ACT Approach

Here are some details about this example:

On DivisionA, users who aren’t in the Managers group, GroupA, or SAS

Administrators are locked out. Such users can’t see or traverse DivisionA or any folders in the DivisionA branch. Managers and members of GroupA have supplemental grants of ReadMetadata and Read permissions on DivisionA; these grants flow through the entire DivisionA branch.

Note:

In order to view a DivisionA report, you need ReadMetadata permission and (in most cases) Read permission to the report’s underlying components (such as information maps, stored processes, and data).

On each content type folder, one or more functional groups has a supplemental grant of WriteMemberMetadata permission. However, functional group access is also constrained by division-level ReadMetadata access. For example, even though all report creators have WriteMemberMetadata permission on the DivisionA reports folder, only those report creators who are members of GroupA can see the folder.

Nothing in these settings prevents creation of a certain type of item. For example, a map creator can create a report and add that report to the map folder or the stored processes folder. Here are some techniques for increasing control:

You can use roles to limit the ability to create reports in SAS Web Report

Studio.

You should limit the ability to register libraries, stored processes and OLAP schemas by managing WriteMetadata permission on application servers.

You can use the map accessibility check configuration option to limit the locations from which SAS Web Report Studio will use relational maps.

You might choose to put the supplemental grants of WriteMemberMetadata permission in additional ACTs (such as MapCreators ACT, ReportCreators ACT) instead of using explicit settings on each folder. Using ACTs is more centralized, which is beneficial in accommodating later changes to the pattern. Of course, the more divisions you have, the more work it would be to update explicit settings, so the more valuable it would be to centralize settings with ACTs.

Consider how you would handle an exception requirement. For example, to let a particular data administrator who isn’t in GroupA contribute to the DivisionA data definitions folder, you might give that user a clear path of grants of

ReadMetadata permission to the folder and supplemental grants of

WriteMemberMetadata and Read permissions on the folder.

Key Points About the Baseline ACT Approach

In general, it isn’t necessary to add protection to the predefined folders (such as the root folder, each user’s My Folder, and the System folder). These folders are protected by default.

The preceding examples don’t add grants of ReadMetadata permission on the

DemoBranch folder because that folder’s parent (the SAS Folders node) is visible to all registered users. The grant of ReadMetadata permission to SASUSERS on the SAS Folders node flows into the DemoBranch.

To hide a branch, apply the Hide ACT to the relevant folder and grant back

ReadMetadata permission to any groups who should have access. Remember that a denial of ReadMetadata permission on a folder prevents navigation to content and folders that are below the hidden folder (and that this can’t be mitigated by a grant of ReadMetadata permission on a lower-level folder or other item).

82 Further Considerations for Permissions on Folders

4 Chapter 6

To enable a group to contribute content to a particular folder, give that group a grant of WriteMemberMetadata permission on that folder and consider applying the Protect ACT to each immediate subfolder.

Note:

This protects lower-level folders that inherit the contributing group’s

WriteMemberMetadata permission grant (from the parent folder) as a grant of

WriteMetadata permission (on the child folder). If you don’t protect a child folder, the contributing group can rename, delete, or change permissions on that folder.

To enable content contributions to the child folder, grant WriteMemberMetadata permission on that folder (and consider repeating the denial of WriteMetadata permission on any subfolders that are below that folder).

Note:

Any content contributors who register cubes must have WriteMetadata permission on the OLAP schema. By default, the schema is in the SAS Folders/

Shared Data/ SASApp - OLAP Schema

folder.

If you want a group to access data through cubes, information maps, or the metadata LIBNAME engine, give that group a grant of Read permission on the folder that contains the relevant items. For any folder where you add a grant of

Read permission, determine whether you want that grant to flow through to the subfolders. Apply the LimitData ACT to any immediate subfolders where you want to prevent data access. The navigational requirement for a clear path of

ReadMetadata permission doesn’t apply to the Read permission.

The examples in this chapter ensure that content contributors have Read permission to the resources that they use. If you have a content contributor who isn’t also a content consumer, you can choose to not provide Read permission. For example, if you give a user ReadMetadata permission but not Read permission to an information map, that user can still design the map (but can’t perform tasks such as testing queries).

You might be able to save some time by using this technique:

Create one sub-branch (for example, the DivisionA branch in the preceding examples). The folders should have appropriate permission settings but contain no content.

Copy that empty sub-branch to create the other branches (for example, to create the DivisionB folders). Change the folder name on the copy and update the settings as necessary. Often, you only have to remove and add a few supplemental grants.

Note:

If this technique proves useful, consider keeping an empty template branch that is visible only to administrators. You can use the template if you need to add more branches later.

Further Considerations for Permissions on Folders

Consolidation of ACTs

In general, consolidation (using one pattern in all of the places where it is appropriate) is beneficial, because it simplifies management. However, it might be appropriate to maintain two ACTs that have the similar patterns in circumstances such as these:

You anticipate that access requirements might diverge. For example, if you think you will eventually separate folder administration from server administration, you might create a SystemProtect ACT for items that aren’t in the folder tree.

Permissions on Folders

4 End Users, Folders, and Permissions

Note:

Another example is that this chapter suggests that you use the baseline

Protect ACT to protect servers and folders, but doesn’t demonstrate another legitimate use of that ACT, to protect the ACTs themselves. This use was omitted from the introductory information about the baseline ACTs only in the interest of avoiding confusion in the initial discussion. Consider returning to the

Authorization

tab of each ACT, removing the explicit settings, and applying the

Protect ACT.

You want to use a pattern that is similar to but not exactly the same as one of the predefined ACTs. For example, the baseline Hide ACT is not very different from the predefined Private User Folder ACT. We strongly recommend that you do not modify or delete the predefined ACTs, because these ACTs are an integral part of the protections that are set up for you during installation. The usage of each predefined ACT requires certain settings. Modifying the settings on a predefined

ACT can compromise the security that that ACT provides.

Separated Administration

If you need to separate administration privileges by department, the approach in this chapter is not granular enough. If you don’t want the SAS Administrators group to have universal access, consider creating parallel sets of baseline ACTs.

For example, to separate administration for an East region and a West region, you might create ACTs such as Hide_East, Hide_West. In each baseline ACT pattern, you would replace the SAS Administrators group with a narrower administrative group (for example, East_Admins, West_Admins). The denials to PUBLIC and grants to the SAS

System Services group would not change. Any unrestricted users can still access everything.

End Users, Folders, and Permissions

Proper use of the WriteMetadata and WriteMemberMetadata permissions protects a folder structure. Keep in mind that end users can affect access to content as follows:

A user who can update an item can add settings on that item. You can’t prevent this by limiting the availability of SAS Management Console because users can set permissions in other applications (for example, SAS Information Map Studio, SAS

OLAP Cube Studio, SAS Data Integration Studio, SAS Enterprise Guide, and the

SAS Add-In for Microsoft Office).

A user who can contribute items to a folder can also add subfolders below that folder. You can’t prevent this by limiting the availability of SAS Management

Console because users can add folders in other applications (for example, SAS

Information Map Studio, SAS OLAP Cube Studio, SAS Data Integration Studio,

SAS Enterprise Guide, and the SAS Add-In for Microsoft Office).

If you give someone CheckInMetadata permission on a folder, that person can update or delete the folder (through change management activities), as well as check in content to that folder. Change management is an optional feature that is available only for SAS Data Integration Studio.

C H A P T E R

Permissions on Servers

Managing Access to Server Definitions

Protecting Server Definitions

Hiding Server Definitions

Managing Access to Server Deﬁnitions

Server metadata is not automatically protected. We recommend that you limit access to server metadata as follows:

To protect definitions, use the WriteMetadata permission to limit the ability to update or delete server metadata.

If you want to limit use of a particular server, use the ReadMetadata permission to hide that server’s definition.

Protecting Server Deﬁnitions

In the initial configuration, the Server Manager capability is available to only the

SAS Administrators group. This provides some protection for server definitions. For greater security, use permissions to define access as follows:

The SAS Administrators group should be able to administer, update, and delete all server definitions.

Users who assign libraries, stored processes, or an OLAP schema to an application server must have WriteMetadata permission for that application server.

No other users should be able to update or delete server definitions.

To efficiently set the permissions, create and use an access control template (ACT).

This enables you to avoid individually setting the same grants and denials on multiple pieces of server metadata. If you want to enable regular users to assign libraries, stored processes, or an OLAP schema to a particular application server, supplement the ACT settings with a grant of WriteMetadata permission on that application server. The following instructions are one way to set the permissions:

Log on to SAS Management Console as a member of the SAS Administrators group (for example, sasadm@saspw). Select the Plug-ins tab.

(Optional) To examine the current settings:

a b

Expand Server Manager, right-click the SASApp application server select Properties.

and

On the Authorization tab, select SASUSERS. Notice that this group (which includes all registered users) has both ReadMetadata and WriteMetadata

86 Protecting Server Deﬁnitions

4 Chapter 7

permissions. The application server inherits these grants from the standard repository-level settings. Click OK to close the dialog box.

To create the ACT:

a b

Expand Authorization Manager, right-click Access Control Templates, and select New Access Control Template.

On the General tab, enter a name such as Protect.

Note:

If you already have a Protect ACT, verify that the pattern on that

ACT’s Permission Pattern tab is correct and that settings on that ACT’s

Authorization

tab protect the ACT itself. Then, proceed to step 4.

On the Permission Pattern tab, define settings that you want to apply to all server metadata:

i ii

Click Add. In the Add Users and Groups dialog box, clear the Show Users check box. Move PUBLIC and SAS Administrators to the Selected

Identities

list box and click OK.

On the Permission Pattern tab:

Select PUBLIC and set the denials in the following table

Remove the grant of ReadMetadata permission for PUBLIC by clicking the already selected grant ReadMetadata check box. This clears that check box so that the pattern neither grants nor denies this permission to PUBLIC.

Note:

A grant of ReadMetadata permission is automatically added for each user or group that you add to a Permission Pattern tab.

The purpose of the Protect ACT is to limit the ability to update or delete items, not to change the visibility of items, so it is important to undo the automatically created grant of ReadMetadata permission for

PUBLIC. Do not instead add a denial of ReadMetadata permission for

PUBLIC. That denial would interrupt the grant of this permission for

SASUSERS that flows through from the repository ACT.

Select SAS Administrators and set the grants in the following table.

For this group, you can leave the automatic grant of ReadMetadata permission in place.

Table 7.1

The Protect ACT

Group

PUBLIC

Permission Pattern

Denial WriteMetadata, WriteMemberMetadata,

CheckInMetadata, Write, Administer

SAS

Administrators

Grant WriteMetadata, WriteMemberMetadata,

CheckInMetadata, Write, Administer, ReadMetadata

1 Gives SAS Administrators exclusive write access to metadata.

To increase reusability, this pattern includes extra permissions.

On the Authorization tab, add explicit you are creating: settings to protect the ACT that

Note:

If the Users and Groups list box on the ACT’s Authorization tab is empty, click OK to save the ACT. Then, right-click the new ACT, select

Properties

, and select the Authorization tab again.

Select PUBLIC and deny WriteMetadata permission. Leave the indirect

(gray) ReadMetadata setting in place.

Permissions on Servers

4 Protecting Server Deﬁnitions

Select SAS Administrators and grant WriteMetadata permission.

Leave the indirect (gray) ReadMetadata setting in place.

4 e

Click OK.

(Optional) If you want to allow some nonadministrators to assign libraries, stored processes, or an OLAP schema, and you don’t already have a group that represents those users, create a new custom group.

Note:

As an alternative to creating a group for only this purpose, you can skip this step and instead assign the permissions to specific users in step 5c.

a b c d

Right-click User Manager and select New

I Group.

On the General tab, enter a name such as Data Admins.

On the Members tab, move users (or groups) to the Selected Identities list box.

Click OK to save the new group. You will grant WriteMetadata permission to this group in step 5c. This group doesn’t participate in the ACT’s pattern because this group needs WriteMetadata permission on only some of the target objects.

To set the protections:

a b

Expand Server Manager, right-click the first application server is your first pass) and select Properties.

(if this

On the Authorization tab, click Access Control Templates. In the Add and Remove Access Control Templates dialog box, move the Protect ACT to the Currently Using list box (you have to expand the Foundation node to get to the ACT). Click OK to return to the Authorization tab.

Note:

Review the revised settings. Notice that SASUSERS is now denied

WriteMetadata permission and that PUBLIC and SAS Administrators have some green settings . The green settings come from the Protect ACT.

(Optional) If the current item is an application server to which nonadministrators will assign libraries, OLAP schemas, or stored processes, click Add, add one or more identities to the Authorization tab, and give each of those identities an explicit grant of WriteMetadata permission.

For example, you might assign the grant to a group (such as GroupA) or to individual users.

d e

Note:

Don’t extend WriteMetadata access to the SASMeta application server, because that server should be used for only a few specialized administrative tasks.

Click OK to save the settings for this object.

Repeat steps 5a-d for every immediate child of Server Manager (except the table server). Immediate children include objects such as other application servers, third-party servers, the share server, the content server, and spawners.

Apply the Protect ACT to every logical server that is under an application server where you added an individual grant of WriteMetadata permission (for SASUSERS or a custom group such as Data Admins).

Note:

This protects lower-level server metadata that would otherwise inherit the nonadministrator’s WriteMetadata grant from the application server. This also prevents nonadministrators who have WriteMetadata permission on the application server from deleting that application server.

The following table summarizes typical protections.

88 Hiding Server Deﬁnitions

4 Chapter 7

Table 7.2

Example: Protecting Server Deﬁnitions

Object

ACT

Added Settings

Supplemental Grants

SASApp Protect DataAdmins: +WM

Each logical server inside SASApp

SASMeta

Protect

(none)

Protect

(none)

(none) Other immediate children of

Server Manager

Protect

* Except the table server, which does not need any changes.

Hiding Server Deﬁnitions

Initially, all registered users can use almost all servers. In general, the SASUSERS group has the ReadMetadata permission on all server metadata.

Note:

The logical workspace server within the SASMeta application server has limited availability. This avoids the potentially confusing situation in which a regular user is offered the SASMeta server context in applications such as SAS Enterprise Guide.

SASMeta

should be used only as instructed in a few specialized administrative tasks.

These initial settings are appropriate until you want to allow only certain users to use certain servers. Here are some reasons why you might choose to limit use of a server:

3 to create different levels of host access from a particular server component ,

3 logical server , or application server . This is one part of the configuration.

to direct high priority users to a server on hardware that offers superior performance.

to direct power users to a server with settings that offer advanced options.

to enable users in SAS Information Map Studio to use a standard workspace server even when a logical pooled workspace server is present.

If you choose to limit use of a server, preserve access as follows:

Make sure that the SAS System Services group has ReadMetadata permission for server metadata. This enables the SAS Trusted User to see server definitions.

This is necessary because the object spawner uses the SAS Trusted User to discover and read all server metadata.

Note:

Users should not be members of the SAS System Services group. This group is for service identities. In the standard configuration, the only member of this group is the SAS Trusted User.

Make sure that the SAS General Servers group has ReadMetadata permission for server metadata. This enables the metadata identity of the launched server to see the server definition. This is a requirement for stored process servers and pooled workspace servers. This isn’t a requirement for standard workspace servers.

Note:

Users should not be members of the SAS General Servers group. This group is for service identities. In the standard configuration, the only member of this group is the SAS Trusted User.

Permissions on Servers

4 Hiding Server Deﬁnitions

In general, the SAS Administrators group should have ReadMetadata permission for all server metadata.

In order to use a server-side pooled workspace server, a user must have the

ReadMetadata permission for that server and for a standard logical workspace server definition within the same application server. An application server that contains only a server-side pooled workspace server is not accessible to users through SAS clients.

Any user who will use a particular server needs ReadMetadata permission for that server, with these exceptions:

The requirement for ReadMetadata permission doesn’t apply to requests to use a client-side pooled workspace server. A user can use a client-side pooled workspace server even if that user can’t see that server definition.

The requirement for ReadMetadata permission isn’t enforced if the Use

Server Access Security

check box on a logical server’s Options tab is present and not selected. This check box should always be selected.

To efficiently set the permissions, create an access control template (ACT) that includes the core grants and denials that you would use when you hide any server. To enable selected users to use a particular server, supplement the ACT settings with a grant of ReadMetadata permission on that server. The following instructions explain one way you can set these permissions:

Log on to SAS Management Console as a member of the SAS Administrators group (for example, sasadm@saspw). Select the Plug-ins tab.

(Optional) To examine the current settings:

3 a b

Expand Server Manager, right-click the server or server component that you are limiting use of and select Properties.

On the Authorization tab, select SASUSERS. Notice that this group (which includes all registered users) has ReadMetadata permission. The application server inherits the grant from the standard repository-level settings. Click OK to close the dialog box.

To create the ACT:

a b c

Expand Authorization Manager, right-click Access Control Templates, and select New Access Control Template.

On the General tab, enter a name such as HideServer.

On the Permission Pattern tab, define general settings for hiding servers:

i ii

Click Add. In the Add Users and Groups dialog box, clear the Show Users check box. Move PUBLIC, SAS Administrators, SAS General Servers, and SAS System Services to the Selected Identities list box and click OK.

On the Permission Pattern tab:

Select PUBLIC and add a denial of ReadMetadata permission.

Make sure that the other three groups each have a grant of

ReadMetadata permission.

Table 7.3

The HideServer ACT

Group

PUBLIC

SAS Administrators

SAS General Servers

Permission Pattern

Denial ReadMetadata

Grant ReadMetadata

SAS System Services Grant ReadMetadata

1 Gives SAS Administrators and service identities exclusive read access to metadata.

90 Hiding Server Deﬁnitions

4 Chapter 7

This pattern, when applied to a standard workspace server, grants a little more access than is strictly necessary. For a standard workspace server, the SAS General Servers group doesn’t need ReadMetadata permission. If you want to avoid this, consider omitting the SAS General

Servers group from this ACT and remembering to add an explicit grant for this group when you are hiding a stored process server or pooled workspace server.

Administrators group.

Note:

If the Users and Groups list box on the ACT’s Authorization tab is empty, click OK to save the ACT. Then, right-click the new ACT, select

Properties

, and select the Authorization tab again.

Click OK.

(Optional) If you don’t already have a group that represents the users who will use the server, create a new custom group.

a b c d

Right-click User Manager and select New

I Group.

On the General tab, enter a name such as GroupA.

On the Members tab, move users (or groups) to the Selected Identities list box.

Click OK to save the new group. You will grant ReadMetadata permission to this group in step 5c. This group doesn’t participate in the general pattern because this group doesn’t need ReadMetadata permission on all servers.

Note:

As an alternative to creating a group for only this purpose, you can skip this step and instead assign the permissions directly to specific users in step 5c.

To set the permissions:

a b

Under Server Manager, right-click the server that you are limiting use of and select Properties.

On the Authorization tab, click Access Control Templates. In the Add and Remove Access Control Templates dialog box, move the HideServer ACT to the Currently Using list box (you have to expand the Foundation node to get to the ACT). Click OK to return to the Authorization tab.

c d

Note:

If the Currently Using list already includes another ACT (such as the Protect ACT), don’t remove that assignment.

Note:

Review the revised settings. Notice that SASUSERS is now denied

ReadMetadata permission and that PUBLIC and SAS Administrators have some green settings

ACT.

. The green settings come from the HideServer

Click Add, add one or more identities to the Authorization tab, and give each of those identities an explicit grant of ReadMetadata permission.

For example, you might assign the grant to a group (such as GroupA) or to individual users.

Click OK to save the settings for this object.

For example, the following table summarizes settings that you might add to provide mutually exclusive access to two server components beneath a standard workspace server that is configured for SAS token authentication:

Permissions on Servers

4 Hiding Server Deﬁnitions

Table 7.4

Example: Hiding Server Deﬁnitions

Object

ACT

Added Settings

Supplemental

Grants

HideServer GroupA: +RM SASApp - ServerA

SASApp - ServerB HideServer GroupB: +RM

1 These settings don’t determine which of the users who can see the server can also update or delete the server. See the preceding topic, "Protecting Server Definitions."

Note:

Someone who has ReadMetadata permission for both ServerA and ServerB

(for example, members of the SAS Administrators group) uses the first server in the object spawner’s list of servers.

If you are limiting use of a logical server or server component, ensure that the Use

Server Access Security

check box on the logical server’s Options tab is selected. If the check box is present and not selected, requirements for

ReadMetadata permission for that server and its components are not enforced.

This option affects only enforcement of the ReadMetadata permission.

Note:

User access to a client-pooled workspace server is determined by the user’s puddle group memberships, not by permissions on the server definition.

C H A P T E R

BI Row-Level Permissions

About BI Row-Level Permissions

Filtering Techniques for BI Row-Level Permissions

How to Implement BI Row-Level Permissions

Preliminary Tasks

Data Modeling

Overview and Examples

Content of a Security Associations Table

Format of a Security Associations Table

Creation and Maintenance of a Security Associations Table

100

Information Map Tasks

100

Overview

100

How to Add a Security Associations Table to an Information Map

100

How to Create an Identity-Driven Filter

101

How to Assign a Filter for Row-Level Permissions

102

Verification

102

Example: Using BI Row-Level Permissions

103

Assumptions and Data Model

103

Implementation and Testing

103

Variation 1: Use External Identity Values for Filtering

105

Variation 2: Apply Different Filtering Logic to Different Groups

105

BI Row-Level Permissions, Identity-Driven Properties, and Missing Values

106

About BI Row-Level Permissions

BI row-level permissions limit access to SAS data and third-party relational data when it is accessed through an 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.

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.

BI row-level permissions provide filtering whenever a SAS data set or third-party relational data is accessed through an information map. However, comprehensive security that incorporates this filtering requires a high-security configuration of SAS

Web Report Studio. See “Preliminary Tasks” on page 95.

The following figure depicts how BI row-level permissions are incorporated when a report is generated. In the figure, a user requests access to a report that includes data

94 About BI Row-Level Permissions

4 Chapter 8 for which row-level permissions have been defined dynamically. See “Identity–Driven

Properties” on page 66. For each step of the report-generation process, the figure depicts the access control activities in the metadata layer.

Figure 8.1

Report-Generation Process

Report Generation Activities

Joe requests to view the report.

Report Definition reference to information map

Report definition is processed.

Information map is processed.

Joe’s value for

SAS.ExternalIdentity is substituted into the filter.

A query that incorporates the resolved filter is generated.

Metadata server enforces

Joe’s ReadMetadata access to information map.

Information Map

Query select * from Orders

Filter where EmpID=&SAS.ExternalIdentity;

Metadata server enforces

Joe’s ReadMetadata access to table and column definitions.

SAS Intelligent Query Services requires Joe to have Read access to the information map in order to access any data through the information map.

Orders Table

EmpID

1234

5151

2233

5678

5151

1234

Name

Tara

Joe

Marcel

Henri

Joe

Tara

Orders

245

306

180

224

Data server pre-filters the data as specified in the query that was generated by

SAS Intelligent Query Services.

Report is compiled using data that is retrieved by the generated query.

Access Control Activities

Metadata server enforces

Joe’s ReadMetadata access to report.

Report is displayed for Joe. Rendered report includes only those rows where “5151” is the employee ID.

The overall flow is the same as for any other report: the report definition and underlying information map are processed, a query is generated to retrieve the data, and the report is displayed. These are the row-level security aspects of the process:

The information map includes a filter that is assigned to a particular metadata

identity. This example uses an identity-driven property in a filter that is based on each group member’s employee ID. The filter is assigned to a group to which Joe

BI Row-Level Permissions

4 Preliminary Tasks

3 belongs. At run time, SAS Intelligent Query Services uses information from the metadata repository to substitute Joe’s employee ID into the filter. The resolved, user-specific form of the filter is incorporated into the generated query. The filter is used to screen the target table before the rest of the generated query runs.

The target data includes information that corresponds to the filter. In this example, the corresponding information consists of user-specific employee ID values in the EmpID column within the Orders table. The data server uses these values to filter the data as specified in the query that was generated by SAS

Intelligent Query Services.

Filtering Techniques for BI Row-Level Permissions

To ensure that target data is prescreened by a filter before any other criteria are applied, incorporate that filter into an information map as a prefilter. Use one of these methods:

To use a filter as an authorization-based prefilter, assign it to users or groups as part of an information map’s access controls. The filter is evaluated as a permission condition. See “Authorization Decisions” on page 62.

To use a filter as a general prefilter, attach it to an information map as part of the information map’s properties. The filter applies to everyone. The filter functions as an additional restriction and operates independently of any access controls that might grant broader access.

Both methods support dynamic filters. See “Identity–Driven Properties” on page 66.

Table 8.1

Summary of BI Row-Level Filtering Techniques

Filter Method

Authorizationbased

Identitydriven

General

Static

Authorizationbased

General

Typical Usage

Per-person access distinctions for every member of a particular group. You create one identity-driven filter and assign it to a group. For example, each user in GroupA can

see his or her own salary information.

Per-person access distinctions for everyone. You create one identity-driven filter and attach it directly to the information map (not to any particular user or group). For example, everyone can see his or her own salary information.

A few distinct subsets. You create a different filter for each subset and assign each filter to a different group. For example, each user in GroupA can see sales totals for the

West region; each user in GroupB can see sales totals for the East region.

One fixed subset for everyone. This is not a row-level method because it does not yield different results for different users. For example, everyone can see global sales totals.

How to Implement BI Row-Level Permissions

Preliminary Tasks

If you need comprehensive security, set up the high-security configuration of SAS

Web Report Studio. This prevents regular users from circumventing row-level

96 Preliminary Tasks

4 Chapter 8 filters by accessing the target tables directly (without going through the information map that enforces the filters). In the high-security configuration, SAS

Web Report Studio uses a privileged account to fetch the data. Regular users have only mediated access to the target tables.

In the following environments, you might not need the high-security configuration:

3 prototype environments environments that do not have strict security requirements environments in which a firewall separates untrusted users environments in which untrusted users do not have the tools, knowledge, or operating system privileges to access files and metadata on the server tier

For instructions for setting up the high-security environment, see "Configure a

Client-side Pooling Workspace Server to Enforce Row-Level Security" in the chapter "Configuring Client-side Pooling" in the SAS Intelligence Platform:

Application Server Administration Guide.

Make sure that appropriate coarse-grained controls are in place for users.

Table 8.2

Metadata Layer Coarse-Grained Controls

Access

All rows

No rows

Some rows

Target Table

Grant Read, ReadMetadata

Deny Read, ReadMetadata

Grant Read, ReadMetadata

Information Map

Grant Read, ReadMetadata

Grant

Read, ReadMetadata

Grant Read

, ReadMetadata

1 Set these grants if the "No rows" users access other tables through this information map.

2 For authorization-based prefilters, this must be an explicit grant.

Note:

In the high-security configuration, only the restricted puddle account and

IT staff who test queries in SAS Information Map Studio have physical access to the target table. If you use server-side pooling, only the server launch credential should have physical access to the target table.

If the target data is in a third-party database, enable authentication to that server.

Make sure that IT staff who test queries against the data from SAS

Information Map Studio can authenticate to the DBMS server. For example, you can store individual or group DBMS credentials for those users, or require those users to interactively provide a DBMS user ID and password.

See “How to Store Passwords for a Third-Party Server” on page 174.

Make sure that regular users can access the DBMS server. For example, you can store individual or shared DBMS credentials for users as you did for the

IT staff.

Note:

In the high-security configuration, you use a different approach so that physical access for regular users is mediated by a privileged service account.

Plan how you will create the data subsets that will narrow grants of the Read permission for each user. Your choice will be affected by the number and type of access distinctions that you are making, the information that your data already contains, and your plans for enhancing your existing data to support row-level filtering. See “Filtering Techniques for BI Row-Level Permissions” on page 95.

Note:

In a situation in which multiple filters (multiple distinct permission conditions) apply to a particular user as a result of the user’s group memberships,

BI Row-Level Permissions

4 Data Modeling

the subset of data that is available to that user is determined by identity precedence. See Table 5.14 on page 69.

Data Modeling

Overview and Examples

It is usually necessary to enhance existing data to include information that works with the filters that you want to use. For example, consider a four-person company with a flat organizational structure and a business requirement that each employee sees only his or her own order information. The order information is stored in this table:

Figure 8.2

Orders Example: Target Table

EmpID

1234

5151

2233

5678

5151

1234

ORDERS

Orders

245

306

180

224

Assume that you didn’t import users (so you don’t have SAS.ExternalIdentity values in the metadata that correspond the EmpID values in the ORDERS table). To avoid setting up a different filter for each user, you decide to use the SAS.PersonName

identity-driven property. Create a table that maps each user’s PersonName (from the

Name

field on the General tab of the user’s definition) to the user’s employee ID. The following figure depicts how that table is used to prescreen the data for each user.

Figure 8.3

Orders Example: Data Model

SAS Metadata Repository

PersonName: Joe Smith

Filter:

Where SASName=

&SAS.PersonName;

Security Associations Table

EMPLOYEE_INFO

SASName

Tara O’Toole

EmpID

1234

Joe Smith

Marcel Dupree

Henri LeBleu

5151

2233

5678

Inner join of subset:

EMPLOYEE_INFO.EmpID=ORDERS.EmpID

Target Table

EmpID

ORDERS

Orders

1234 245

5151

2233

5678

306

5151

1234

180

224

98 Data Modeling

4 Chapter 8

Another simple example is to subset employee performance information based on each manager’s external identity value, as depicted in the following figure.

Figure 8.4

Performance Example: Data Model

SAS Metadata Repository

ExternalIdentity: 5151

Filter:

Where ManagerID=

&SAS.ExternalIdentity;

Security Associations Table

Organization

ManagerID Employee

5151

Tara

Marcel

Henri

Jacques

Inner join of subset:

Organization.Employee=Performance.Employee

Target Table

Performance

Employee Rating

Tara

Marcel

Henri

Jacques

Another example is to subset sales information by each salesperson’s geographic responsibilities. Assume that there is a metadata group for each country and that some employees have responsibilities in multiple continents. The following figure depicts continent-level subsetting based on each salesperson’s metadata group memberships.

Figure 8.5

Sales Example: Data Model

SAS Metadata Repository

PUBLIC

SASUSERS

Spain Morocco

Filter:

Where SASgroup is in

&SAS.IdentityGroups;

Security Associations Table

GroupToRegion

SASgroup Region

PUBLIC

Morocco

Japan

France

Lebanon

Spain

GLOBAL

Africa

Asia

Europe

Middle East

Europe

Inner join of subset:

GrouptoRegion.Region=Sales.Region

Target Table

Sales

Region Units

Asia

GLOBAL

Africa

Europe

Middle East

275

BI Row-Level Permissions

4 Data Modeling

This approach provides aggregated retrieval and flattens the group structure. Each user gets all rows that are permitted for any groups that the user belongs to. To enable everyone to see the global totals, the security associations table includes a row that pairs the PUBLIC group with global totals.

Content of a Security Associations Table

A security associations table is a type of table that documents the relationships between a user and some criterion on which you are making access distinctions. When access distinctions are based on each user’s place within an organizational hierarchy, the security associations table must contain a representation of the reporting relationships within the organization. If access distinctions are based on some other criterion (such as each user’s project assignments), then the security associations table should reflect that criterion.

Format of a Security Associations Table

BI row-level permissions do not require that the security associations table have a particular format. However, the format of a security associations table can affect filter performance. This topic describes a format that supports efficient hierarchy-based filtering. This format is useful for many common scenarios, because security policies are often hierarchical. For example, a typical business requirement is that a manager can see data for all of the employees that he or she manages either directly or indirectly.

The following figure depicts two ways to structure a security associations table that documents each user’s place in a simple organizational hierarchy. The sparse version of the table includes only direct reporting relationships; information about indirect relationships must be derived. The fully articulated (or robust) version explicitly includes indirect reporting relationships along with direct reporting relationships; this is advantageous for query performance.

Figure 8.6

Representations of an Organizational Hierarchy

Organization Hierarchy

CEO

Vice President1 Vice President2

Security Associations Table

(sparse)

Reporting Relationships

Manager

CEO

Employee

Vice President1

CEO

Vice President1

Manager1

VicePresident2

Manager1

Manager2

Staff Person1

Staff Person2

StaffPerson1

Manager1

StaffPerson2

Manager2

Security Associations Table

(fully articulated)

Reporting Relationships

Manager Employee

CEO Vice President1

CEO

Vice President1

Manager1

VicePresident2

Manager1

Manager2

Staff Person1

Staff Person2

Manager1

Manager2

Staff Person1

Staff Person2

Staff Person1

Staff Person2

100 Information Map Tasks

4 Chapter 8

The table that uses the fully articulated format explicitly includes not only the hierarchy’s immediate parent-child relationships, but also every other ancestor-descendant association (such as grandparent-child and great grandparent-child). This facilitates simpler queries by eliminating the need to traverse the hierarchy to find all of the descendants of any particular node.

Creation and Maintenance of a Security Associations Table

This topic contains a general discussion about creating and managing a security association table for use with dimensional target data. BI row-level security does not require that target data conform to a particular structure. The description in this topic is for dimensional data, because that is a frequently used structure for query and reporting.

A security associations table is usually created as a new object by traversing an existing sparse table and filling in the indirect relationships to create a fully articulated

(or robust) version of the table. If you do not have an existing sparse table, then you must create that object first.

Note:

If you want to enhance an existing sparse table rather than creating a new table, you should first review current uses of the sparse table to determine whether the additional rows will negatively affect those uses.

In most cases it is helpful to have an index on the column in the security associations table that is used for filtering. In some cases, factors such as the size of the security associations table or query optimization features in a particular data source might negate the need for this index.

The security associations table must be maintained as security relationships change.

This maintenance should be on a schedule that is appropriate for your environment.

Typically, this maintenance is accomplished by a batch process (such as a nightly ETL process against the existing tables). In some cases, updates might be entered directly by an administrator.

Information Map Tasks

Overview

The following figure depicts the row-level permission aspects of information map design.

Figure 8.7

Information Map Design for Row-Level Permissions

Information map without row-level permissions

Incorporate a security assocations table

Create one or more filters

Assign the filters as prefilters

Information map with row-level permissions

The following topics provide generic instructions for each of these four tasks.

How to Add a Security Associations Table to an Information Map

In order to make the security relationship information that you added to the data model available for filtering, you must incorporate that information in an information

BI Row-Level Permissions

4 Information Map Tasks

101

map. To enhance an existing information map to include a new security associations table:

In SAS Management Console, register the new security associations table in the metadata.

In SAS Information Map Studio:

a b c i

Add the table to your information map as a data source.

On the Relationships tab, define an inner join that connects an identifier column in the security associations table with a corresponding column in the target table (or in an intermediate dimension).

Make the security associations table a required table by performing these steps:

Select Edit

I Properties I Information Map, and then select the

Required Tables

tab in the Information Map Properties dialog box.

In the Available tables list, select the table that you are using as a security associations table. Use the arrow button to move the table to the

Required tables

list. Click OK.

Note:

We recommend that you do not create data items from columns in the security associations table. Excluding these column references from the information map prevents their values from surfacing when reports are created in SAS Web Report

Studio.

How to Create an Identity-Driven Filter

To create a filter that is based on an identity-driven property, perform these steps in

SAS Information Map Studio:

Open the information map, save the information map, and select the Design tab.

Select Insert

I New Filter to open the New Filter dialog box.

Enter a name for the filter and select a character data item (or click Edit Data

Item

and use the expression builder to define a character item).

In the New Filter dialog box, from the Enter value(s) drop-down list, select

Derive identity values (for row-level permissions)

The examples column shows what your values are for each property.

The SAS.PersonName value corresponds to the Name field on the General tab of your user definition. This is not always the same as the value of the

Display Name

field.

The SAS.IdentityGroupName value is usually blank and isn’t often useful.

Although the SAS.IdentityGroups property displays only one value, this property actually returns a list of the groups and roles that you belong to.

The SAS.ExternalIdentity value is populated only in certain circumstances.

See “External Identities” on page 226.

Select the row for the identity-driven property that you want to use in the filter.

See “Identity–Driven Properties” on page 66.

Note:

Not all conditions support all identity-driven properties. Make sure that the selection in the Condition drop-down list is appropriate.

Note:

If you use the IdentityGroups property, set the condition to Is equal to or Is not equal to. For this property, these conditions are converted to an IN

(or, NOT IN) statement when the query executes.

Select the Hide from user check box at the bottom of the Definition tab. This prevents the filter from being surfaced (and potentially removed) when reports are created in SAS Web Report Studio.

102 Veriﬁcation

4 Chapter 8

Click OK. The new filter is now available for use in the current information map.

How to Assign a Filter for Row-Level Permissions

To use a filter for security purposes, assign the filter as an authorization-based prefilter or a general prefilter.

To assign a filter as an authorization-based prefilter:

Open the information map, save the information map, and select Tools

Authorization

to open the Authorization dialog box.

In the Users and Groups list, select (or add) the identity that should be subject to the filter.

Make sure that the right user or group is selected. Add an explicit the Read permission.

grant of

Click Add Condition to open the Row-Level Permission Condition dialog box.

In the Selected filters list (the right-hand panel), select the table that you are using as a security associations table.

In the Available filters list, select the filter and then use the arrow button to move the filter to the Selected filters list. Click OK.

In the Authorization dialog box, click Close.

To make your changes take effect, save the information map.

To assign a filter as a general prefilter:

Open the information map, save the information map, and select Edit

Properties

I Information Map.

In the Information Map Properties dialog box, select the General Prefilters tab.

In the Selected filters list (the right-hand panel), select your security associations table.

In the Available filters list, select the filter and then use the arrow button to move the filter to the Selected filters list. Click OK.

Veriﬁcation

In a high security configuration, final verification must be performed from within

SAS Web Report Studio. This testing requires that you log on to that application using different accounts.

If you are using server-side pooling, or if you have physical access to the data, you can do some preliminary testing to check your filter logic from within SAS Information

Map Studio. Before you test an information map from within SAS Information Map

Studio, you should save the information map to ensure that all settings are applied. To test a filter that is based on an identity-driven property, use different accounts to log on to SAS Information Map Studio. To test other filters, temporarily assign the filters to your identity.

Note:

If you are using server-side pooling, your results in SAS Information Map

Studio should be the same as your results in SAS Web Report Studio. See “Choices in

Workspace Server Pooling” on page 192.

BI Row-Level Permissions

4 Implementation and Testing

103

Example: Using BI Row-Level Permissions

Assumptions and Data Model

This example demonstrates how a company could use row-level permissions to manage access to employee data. The example includes these assumptions:

The target tables are registered in the metadata repository.

Except where otherwise noted, users have Read permission for the information maps that they are using.

The data model is a star schema that contains employee and customer data. The security associations table includes both direct and indirect reporting relationships.

The company has set up a high-security configuration of SAS Web Report Studio as specified in “Preliminary Tasks” on page 95.

In this example, the business requirement is to enable managers to see salary information for their employees. One way to meet this requirement is to use the

SAS.PersonName property. The following figure depicts this process for a requesting user who is a high-level manager in the organization.

Figure 8.8

Salary Example: Data Model

SAS Metadata Repository

PersonName: Harry Highpoint

Security Associations Table Definition

(partial)

SECURITY_ASSOC

EMPLOYEE_ID

PARENT_EMPLOYEE_NAME

Target Table Definition

(partial)

ORGANIZATION_DIM

EMPLOYEE_ID

SALARY

Each requesting user’s PersonName is used to filter the security associations table.

This yields a subset that includes only those rows with employees who report (directly or indirectly) to the requesting user. That subset is inner joined to the target table to limit retrieval of salary information.

Implementation and Testing

To implement the filtering for this example:

Create an information map that includes the necessary data and relationships.

a b

In SAS Information Map Studio, open a new information map.

Insert the target table and the security associations table as data sources. In this example, the target table (ORGANIZATION_DIM) contains salary data, and the security associations table (SECURITY_ASSOC) contains a representation of the company’s reporting relationships.

104 Implementation and Testing

4 Chapter 8

On the Design tab, add the data items that you need from the

ORGANIZATION_DIM table (insert the SALARY, EMPLOYEE_ID, and

EMPLOYEE_NAME columns).

Note:

It is a good practice to not create any data items from the

SECURITY_ASSOC table.

2 d e a b f d e c

On the Relationships tab, join the two tables on EMPLOYEE_ID.

Save the new information map to an appropriate folder.

Make SECURITY_ASSOC a required table:

i ii iii iv

Select Edit

I Properties I Information Map.

In the Information Map Properties dialog box, select the Required Tables tab.

In the Available tables list, select the SECURITY_ASSOC table.

Use the arrow button to move the table to the Required tables list, and then click OK.

Create a filter that subsets data by comparing each user’s SAS.PersonName value to the PARENT_EMPLOYEE_NAME values in the security associations table.

Select Insert

I New Filter to open the New Filter dialog box.

Enter a name such as byPersonName for the filter, and then click Edit Data

Item

In the Edit Expression dialog box, select Character from the Type drop-down list. On the Data Sources tab, navigate to Physical Data

SECURITY_ASSOC

I PARENT_EMPLOYEE_NAME, and then click Add to

Expression

Click Validate Expression, and then click OK twice.

In the New Filter dialog box, from the Enter value(s) drop-down list, select

Derive identity values (for row-level permissions)

. A table of identity-driven properties becomes available. See “Identity–Driven

Properties” on page 66.

Note:

Make sure that the value in the Condition drop-down list is Is

equal to

4 f g

In the table of properties, select the SAS.PersonName row.

Click OK. The byPersonName filter is now available for use in the information map.

Assign the filter as a general prefilter:

c d e a b

Select Edit

I Properties I Information Map.

In the Information Map Properties dialog box, select the General

Prefilters

tab.

In the Selected filters box, select the SECURITY_ASSOCIATIONS table.

In the Available filters box, select the byPersonName filter.

Click the right arrow button to assign the byPersonName filter to the

SECURITY_ASSOC table, and then click OK.

Save the information map.

Any administrators who have physical access to the data can test by logging on to

SAS Information Map Studio and running test queries. To verify that the filter is working as expected, log on using different accounts. For example:

For a user who is not included in the security associations table, no salaries should be retrieved.

For the president of the company, all salaries should be retrieved. Note that by default only 100 rows of data are returned when you test an information map.

For a mid-level manager, a subset of salaries should be retrieved.

BI Row-Level Permissions

4 Variation 2: Apply Different Filtering Logic to Different Groups

105

To run a test query from within SAS Information Map Studio:

Select Tools

I Run a Test Query from the main menu.

In the Test the Information Map dialog box, use the arrow button to add the

Salary

and Employee Name items to the Selected items box.

Click Run Test and then examine the data in the Results dialog box.

To test using another account, close the information map, and then select File

Connection Profile

from the main menu.

Note:

Because this is a high-security configuration, final verification must be performed from within SAS Web Report Studio. In a different configuration in which you use server-side pooling, your results in SAS Information Map Studio are the same as your results in SAS Web Report Studio. See “Choices in Workspace Server Pooling” on page 192.

Variation 1: Use External Identity Values for Filtering

This variation describes one way to work with target data that contains employee

IDs (instead of employee names). Modify the main implementation steps as follows:

Verify that users have the external identity values that you expect. If necessary, you can manually add external identity values to the metadata. See “External

Identities” on page 226.

Use the PARENT_EMPLOYEE_ID column instead of the

PARENT_EMPLOYEE_NAME column.

Use the SAS.ExternalIdentity property instead of the SAS.PersonName property.

Variation 2: Apply Different Filtering Logic to Different Groups

This variation addresses these additional business requirements:

Four people who work in a Human Resources department must be able to view salary information for all employees. You have created a user-defined group in the metadata repository for these users (the HR group).

Users who do not have individual metadata identities must not be able to see any of the data. These users have the access that has been defined for the PUBLIC group.

This table summarizes the strategy:

Table 8.3

Information Map Controls

Access Class (User Group)

All rows (Human Resources)

No rows (PUBLIC)

Some rows (SASUSERS)

Information Map

Grant Read, ReadMetadata

Deny

Read, ReadMetadata

Grant Read

, ReadMetadata

1 The information map in this example exists only for the purpose of obtaining salary information, so the "No rows" users do not need to be able to see or use this information map.

2 For each member of SASUSERS, this explicit grant is narrowed by the byPersonName filter that you created in the main example. Here, the filter is used as an authorization-based prefilter.

To set these permissions:

Prepare the information map by using either of these methods:

106 BI Row-Level Permissions, Identity-Driven Properties, and Missing Values

4 Chapter 8

Create a new information map for this variation by completing steps 1 and 2 in the main example.

Reuse the information map from the main example by saving that map with a different name and deassigning the filter that was assigned on the General

Prefilters

tab.

Open the information map and select Tools

I Authorization to open the

Authorization dialog box.

In the Users and Groups list, select PUBLIC. In the Effective Permissions list, add explicit denials for the Read and ReadMetadata permissions.

Click Add. In the Add Users and Groups dialog box, select the HR and SASUSERS groups and then click OK.

In the Authorization dialog box, give SASUSERS explicit and ReadMetadata permissions.

grants of the Read

To limit the SASUSERS grant of the Read permission, assign the byPersonName filter to that group.

Click Add Condition to open the Row-Level Permission Condition dialog box.

b c

Note:

The Add Condition button became available when you added the explicit grant of Read permission.

In the Selected filters list, select the SECURITY_ASSOC table.

In the Available filters list, select the byPersonName filter and then use the arrow button to move that filter to the Selected filters list.

Note:

Unlike a filter that you assign on the General Prefilters tab, this filter applies only to members of the SASUSERS group as evaluated according to the identity hierarchy and access control precedence rules.

Click OK to close the Row-Level Permission Condition dialog box.

In the Authorization dialog box, give the HR group explicit grants of the Read and

ReadMetadata permissions. Because you want this group to be able to view all salaries, do not constrain Read access by adding a permission condition.

In the Authorization dialog box, click Close. To make your changes take effect, save the information map.

With these access controls in place, retrieval is as follows:

Users who don’t have their own SAS identity (PUBLIC-only users) can’t see or use the information map.

Users who have their own SAS identity but aren’t listed in the security associations table can see the information map, but retrieve no rows.

Users who have their own SAS identity, are listed in the security associations table, and are not members of the HR group get only those rows that contain data for their own direct and indirect reports.

Users who are members of the HR group get all rows.

BI Row-Level Permissions, Identity-Driven Properties, and Missing

Values

If a connecting user doesn’t have a value for the identity-driven property that a query uses, the generated query uses an empty string as the substituted value for that identity. If the table against which the query filtering is performed includes empty string values in any rows, those rows are returned to the connecting identity.

BI Row-Level Permissions

4 BI Row-Level Permissions, Identity-Driven Properties, and Missing Values

107

CAUTION:

Returning data in a missing value situation is a new behavior in this release. In previous releases, a missing value generated an error and prevented any rows from being returned.

Here are some alternatives for addressing missing values:

To ensure that data is returned for only those identities who have a value for the property that you are using, make sure that there aren’t any empty string values in the target table’s security key column.

To identify a set of rows that should be returned for identities who don’t have a value for the property that you are using, specify an empty string value for those rows in the target table’s security key column.

Note:

If the target table is in a DBMS, the extra row must contain an empty

(blank) character string (not a NULL value).

To identify a situation in which retrieval is empty due to a missing value for the requesting user’s identity-driven property, include a mapping for the empty string value (’ ’)in your security associations table and one extra row in your target table.

In that row, use the security key that corresponds to the empty string value and include an appropriate error message. This enables the end user to distinguish between the following situations:

3 an empty result set that is caused by the target table not including any rows that match the user’s value for an identity-driven property

3 an empty result set that is caused by the user not having any value for the identity-driven property that a query is using

Note:

If the security associations table is in a DBMS, make sure that the missing value row in that table contains an empty (blank) character string, not a NULL value.

The following figure depicts an example:

Figure 8.9

Example: Error Handling for a Missing External Identity Value

SAS Metadata Repository

ExternalIdentity:

Filter:

Where ManagerID=

&SAS.ExternalIdentity;

Security Associations Table

ManagerID

5151

‘ ‘

2345

Organization

Employee

Tara

Marcel

NoValue

Jacques

Inner join of subset:

Organization.Employee=Performance.Employee

Target Table

Performance

Employee

No ExternalIdentity Found NoValue

Tara

Marcel

Jacques good average excellent

108

C H A P T E R

OLAP Member-Level Permissions

About OLAP Member-Level Permissions

109

How to Assign an OLAP Permission Condition

110

Example: Using Member-Level Permissions

111

Introduction

111

Implementation Process

111

About OLAP Member-Level Permissions

OLAP member-level permissions enable you to limit access to SAS OLAP data by using filters. Each filter consists of an MDX expression that subsets the data in a dimension as appropriate for a particular user or group. The filters are stored in the metadata as permission conditions. This feature relies on the SAS OLAP Server for enforcement. At query time, the server performs the filtering to determine which dimension members should be returned to each requesting user. The server leverages its knowledge to accomplish the filtering efficiently. This also ensures that the filters are applied every time the data is accessed.

When you use OLAP member-level permissions, it is essential to understand these points:

With OLAP data, permission conditions can be specified only on dimension objects.

The SECURITY_SUBSET option can affect results. See the discussion of this option in the topic "Cube Security" in the SAS OLAP Server: User’s Guide.

The members that are returned by the MDX expression must all belong to the dimension on which the permission condition is defined. The returned set of members cannot be a union of members from other dimensions.

A permission condition that filters a non-default hierarchy must include at least one member of the default hierarchy. If a requesting user does not have access to any members in the default hierarchy, then the query fails with a permissions error.

See Also

“Fine-Grained Controls for Data” on page 65

SAS OLAP Server: MDX Guide

SAS OLAP Server: User’s Guide

109

110 How to Assign an OLAP Permission Condition

4 Chapter 9

How to Assign an OLAP Permission Condition

Access the Authorization tab of the dimension permission condition.

for which you are defining a

Note:

In SAS Management Console, you can access dimensions on the Plug-ins tab under Authorization Manager

I Resource Management I By Location I

<your application server>

I <your OLAP schema> I <your cube> I

Dimensions

. In SAS OLAP Cube Studio, navigate to the dimension on the

Inventory

tab.

Select (or add) the user or group whose access to measures you want to limit.

In the permissions list, add an explicit user or group.

Click the Add Authorization button.

grant of the Read permission for that

Note:

If the Edit Authorization button is displayed, a condition already exists for the selected user or group.

In the Add Authorization dialog box, select the Create an advanced MDX

expression

radio button and click Build Formula.

Use the Build Formula dialog box to create a filter that limits the current dimension as appropriate for the user or group that you selected on the

Authorization

tab. Identity-driven properties are available on the Data Sources tab under the Identity Values folder. See “Identity–Driven Properties” on page

66.

OLAP Member-Level Permissions

4 Implementation Process

111

Example: Using Member-Level Permissions

Introduction

This example demonstrates how you can use member-level permissions. These are the security goals in this example:

3 enable company executives to access data based on their areas of responsibility

3 prevent other employees from accessing data in the cube that is used to generate executive reports

The following figure depicts the relevant parts of a company’s organization structure and of the OLAP cube against which the company runs executive reports. Notice that the levels in the cube’s Geography dimension closely correspond to the depicted organizational structure.

Organization Structure

All

Level

Levels in the Geography Dimension

Continent

Level

Country

Level

City

Level

President

Africa

Vice President:

International

Vice President:

Americas

Director: Africa

Director:

Australia/Pacific

Director:

North America

Asia

All

Geography

Australia/

Pacific

Director: Asia

Director: Europe

Europe Germany

Manager:

Germany

Manager:

USA

North

America

USA

Implementation Process

Set these permissions on the cube:

Give the PUBLIC group explicit denials of the Read and ReadMetadata permissions for the entire cube. The data in the cube is used for executive reports only.

Give the company president explicit grants of the Read and

ReadMetadata permissions for the entire cube. This user sees all of the data.

112 Implementation Process

4 Chapter 9

Give the SAS System Services group an explicit grant of the

ReadMetadata permission. You must always preserve the SAS Trusted User’s access to cubes and schemas.

In most cases, some members of the information technology staff will also need access to the data for administrative purposes. Make sure that any such groups or users have explicit permissions.

grants of the Read and ReadMetadata

To assign the permission conditions:

Right-click the cube’s Geography dimension .

f b c d e g

Note:

In SAS Management Console, you can access the dimensions on the

Plug-ins

tab under Authorization Manager

I Resource Management I

By Location

I <your application server> I <your OLAP schema> I <your

cube>

I Dimensions. In SAS OLAP Cube Studio, navigate to the dimension on the Inventory tab.

On the Authorization tab, select (or add) the Vice President Americas user.

In the permissions list, add an explicit grant of the Read permission for the Vice President Americas user. This enables the Add Authorization button.

Click the Add Authorization button,

In the Add Authorization dialog box, select the Create an advanced MDX

expression

radio button and click Build Formula.

In the Build Formula dialog box, paste or build a filter for the Vice President

Americas user and click OK.

On the Authorization tab, click OK to save this permission condition and then return to step 2b to repeat the process for the next executive.

For example, this table contains MDX expressions that you could use to subset the data based on each executive’s area of responsibility.

Table 9.1

Example: MDX Expressions

User

Vice

President

Americas

MDX Expression

{[Geography].[All Geography], Descendants([Geography].[All

Geography].[North

America],[Geography].[Continent],SELF_AND_AFTER)}

Vice

President

International

Except({[Geography].Members}, {Descendants([Geography].[All

Geography].[North

America],[Geography].[Continent],SELF_AND_AFTER)})

Director

North

America

{[Geography].[All Geography],[Geography].[All Geography].[North

America],[Geography].[All Geography].[North America].Children}

{[Geography].[All Geography],[Geography].[All

Geography].[North America],descendants([Geography].[All

Geography].[North America])}

{[Geography].[All Geography].[North America], [Geography].[All

Geography].[North America].Children}

Notes

Use Except to exclude North

America.

Use .Children to include countries.

Alternative: use

Descendants to include countries and cities.

Alternative: exclude the All level.

OLAP Member-Level Permissions

4 Implementation Process

113

User

Director

Africa

Director

Asia

Director

Australia/

Pacific

Director

Europe

Manager

Germany

Manager

USA

MDX Expression

{[Geography].[All Geography].[Africa], [Geography].[All

Geography].[Africa].Children}

{[Geography].[All Geography].[Asia],[Geography].[All

Geography].[Asia].Children}

{[Geography].[All Geography].[Australia/Pacific], [Geography].[All

Geography]. [Australia/Pacific].Children}

Notes

{[Geography].[All Geography].[Europe], [Geography].[All

Geography].[Europe].Children}

{[Geography].[All Geography].[Europe].[Germany], descendants([Geography].[All Geography].[Europe].[Germany])}

{[Geography].[All Geography].[North America].[USA], descendants([Geography].[All Geography].[North

America].[USA])}

Exclude

Europe.*

Exclude North

America.*

* Because this expression excludes a parent level, you should also deny this user the

ReadMetadata permission for the level that you are hiding.

This is a requirement when

OLAP data is accessed through an information map.

114

C H A P T E R

Security Report Macros

Overview of Security Reporting

115

Authorization Data Sets

118

Additional Resources for Building Authorization Data Sets

120

Overview of Security Reporting

Security reporting creates a snapshot of metadata layer access control settings and uses that snapshot in these ways:

3 as a data source for reports about current settings

3 as a data point for comparing settings across time

The first task in security reporting is to extract, filter, and format authorization data for a specified set of identities, permissions, and objects. SAS provides macros that help you perform this task. For example, the following code uses the main security report macro, %MDSECDS, to generate authorization data sets for a specified folder and its contents:

/* connect to the metadata server */ options metaserver=machine-name metauser="sasadm@saspw" metapass="Pwd123";

/* run the main report macro against a target folder */

%mdsecds(folder="\Shared Data\New Stored Processes"); run;

The second task in security reporting is to build reports that run against the authorization data sets. For example, the following code prints some of the data from the preceding example:

/* print the WriteMetadata setting information */ proc print data=work.mdsecds_join noobs width=minimum; var objname publictype identityname WriteMetadata; run;

The output looks like this:

115

116 %MDSECDS

4 Chapter 10

ObjName

New Stored Processes

Shoe Sales Graphics

Shoe Sales by Region

PublicType

Folder

StoredProcess

StoredProcess identityname

PUBLIC

SAS System Services

SAS Administrators

PUBLIC

SAS System Services

SAS Administrators

PUBLIC

SAS System Services

SAS Administrators

SASUSERS

WriteMetadata

Denied Indirectly

Granted by ACT

Denied Explicitly

Denied Indirectly

Granted Explicitly

Denied Indirectly

Granted Indirectly

Granted Explicitly

Because the output is SAS data sets, you can create sophisticated reports by using

SAS reporting techniques such as these:

3 create an information map that uses an authorization data set as its data source and then use SAS Web Report Studio to create reports based on that information map.

write SAS ODS (output display system) code that builds an HTML report against the authorization data sets. For an example, see

SAS-installation-directory\SASFoundation\9.2\core\sample\secrpt.sas

(Windows) or SAS-installation-directory/SASFoundation/9.2/samples/base/

secrpt.sas

(UNIX).

%MDSECDS

Generates authorization data sets. This is the top-level macro (it calls the underlying macros and should be used on its own).

Used in:

Type:

Security reporting

Stand-alone

Requirement:

Connection to the metadata server

Syntax

%MDSECDS (OUTDATA=data-set, <FOLDER="path">,

<INCLUDESUBFOLDERS=YES | NO>, <MEMBERTYPES="list">,

<MEMBERFILTER="expression">, <PERMS="list">, <IDENTITYNAMES="list">,

<IDENTITYTYPES="list">);

OUTDATA

provides a base name for the output. By default, the base name is work.mdsecds.

See “Authorization Data Sets” on page 118.

The following options define the scope of the extraction:

FOLDER

identifies a starting point folder. By default, the starting point is the server root (the first node on the Folders tab in SAS Management Console). If you provide a path

(such as "\Products\SAS Intelligence Platform\Samples"), the starting point is the last folder in the path.

Note:

To avoid having to type a long pathname, copy the path from a child item’s

General

tab into your code.

Security Report Macros

4 %MDSECDS

117

INCLUDESUBFOLDERS

controls whether the entire subtree is included. By default, all objects in the entire subtree are included. If you specify NO, only the immediate contents of the starting point folder are included.

MEMBERTYPES

limits by object type. By default, all public types are included. If you provide a comma-delimited list of types, only those types are included.

You must provide the public type name in its TypeName format. For example, if you access the Advanced tab in the properties dialog box for the Information Map

(relational)

object type, you will see that its TypeName is

InformationMap.Relational

. All public types are displayed on the Folders tab in

SAS Management Console under System

I Types.

Note:

If you use this option, examine the output. The log doesn’t display errors or warnings for incorrectly specified types.

MEMBERFILTER

limits by metadata attribute value. By default, no filter is applied. If you provide an expression, only objects that meet the criteria are included. The format for the expression is @attribute-name comparison-operator ’value’ (for example, @objID

=’A5HDAJSI.B90006Y5’

or @Name =:’Salary’).

Comparison operators for character data include = (equals), =: (begins with), ?

(contains), and ne (not equals).

Metadata attributes are associated with an object’s metadata type (not public type). Here are two common attributes: objID is the object’s metadata ID, which is displayed on the object’s

Inheritance

tab.

Name

Note:

To access an object’s Inheritance tab, open the object’s properties dialog box, select the Authorization tab, and then click Advanced. This feature is available only to unrestricted users.

4 is the object’s name, which is displayed in the Name field on the object’s General tab.

To find additional attributes:

Determine the MetadataType of the object you are interested in. The type is displayed on the object’s Inheritance tab. For example, if you look at the

Inheritance

tab for your My Folder , you will see that the MetadataType for a folder is Tree. MetadataType is a low level, internal classification.

In the reference documentation for the metadata model, look up that

MetadataType to find the names of its attributes.

PERMS

specifies which permissions to include. By default, all permissions that are supported for each object type are included for objects of that type. If you provide a comma-delimited list of permissions, only those permissions are included. Even if the permissions in your user interface are translated, you must specify the

English-language permission names (for example, ReadMetadata).

IDENTITYNAMES

specifies which identities to include. By default, only the named participants (the identities that are listed on an object’s Authorization tab) are included. If you provide a comma-delimited list of identity names, only those identities are included.

List identities by their names, not their display names.

118 Authorization Data Sets

4 Chapter 10

If you use this option, you must also use the IDENTITYTYPES option.

IDENTITYTYPES

specifies whether names in the IDENTITYNAMES list correspond to users or to groups. For example, the first name listed in the IDENTITYNAMES parameter must match the first value in the IDENTITYTYPES list. Valid values in this list are

Person

and IdentityGroup.

Examples

This code extracts information about permissions on the objects in the Sales folder but doesn’t include objects in subfolders:

%mdsecds(folder="\Shared Data\Sales", includesubfolders=no);

This code extracts information about permissions on tables and schemas in the Sales folder and its subfolders:

%mdsecds(folder="\Shared Data\Sales", membertypes="Library,OLAPSchema");

This code extracts information that indicates which libraries a particular user (the

SAS Demo User) can see:

%mdsecds(identitynames="sasdemo", identitytypes="Person", membertypes="Library", perms="ReadMetadata");

This code extracts information that indicates which stored processes two users (the

SAS Demo User and Tara O’Toole) can see:

%mdsecds(identitynames="sasdemo,totoo", identitytypes="Person,Person", membertypes="StoredProcess", perms="ReadMetadata");

This code extracts information that indicates which reports one user and one group

(the SAS Demo User and PUBLIC) can modify:

%mdsecds(identitynames="sasdemo,PUBLIC", identitytypes="Person,IdentityGroup", membertypes="Report", perms="WriteMetadata");

This code extracts information that indicates who can view reports that include the word "Salary" in their names:

%mdsecds(membertypes="Report", perms="ReadMetadata", memberfilter="@Name ? ’Salary’");

This code extracts permission settings for an item that is referenced by its object ID:

%mdsecds(memberfilter="@objID = ’A5HDAJSI.B90006Y5’");

Authorization Data Sets

Table 10.1

work.mdsecds_join (the Primary Table for Reporting; Combines objs, permsw, pconds)

Column Name Column Contents

IdentityDispName The display name of this user or group (for example, SAS Demo User). If there is no display name, this column contains the same value as the IdentityName column.

IdentityName The name of this user or group (for example, sasdemo).

Security Report Macros

4 Authorization Data Sets

119

Column Name

IdentityType

Location

Column Contents

Person

, IdentityGroup, or Role.

A container path for this object (for example,

\Shared Data\Sales

). The path usually consists of folder names but can also include names of other containers.

The date when this object was created.

MetadataCreated

MetadataType The internal metadata type for this object.

MetadataUpdated The most recent date that this object was updated.

ObjId

ObjName

ObjUri

ParentObjId

Permissions

(permissions)

PublicType

The metadata ID for this object (for example, A5HDAJSI.B900066J).

The name of this object (for example, Shoe Sales by Region).

The uniform resource identifier for this object (for example, omsobj:PhysicalTable/

A5XT9KUX.B80000001

The metadata ID for this object’s immediate parent. See “Inheritance Paths” on page 53.

A list of the permissions to inspect for this object. If the list is blank, then all permissions that are applicable to this type of object are inspected.

A separate column for each permission. Each cell in these columns contains a value that indicates whether this permission is effectively granted or denied for this identity. The type of setting (explicit, ACT, or indirect) is also indicated. For example, Granted by ACT or Denied

Explicitly

or Granted Indirectly. See Table 4.1 on page 41.

The public metadata type for this object.

Table 10.2

work.mdsecds_objs (Contains Folder and Member Information)

Column Name

Desc

Location

MetadataCreated

MetadataType

MetadataUpdated

ObjId

ObjName

ObjUri

ParentObjId

Permissions

PublicType

Column Contents

Description information for this object. For most objects, this information comes from the

Description

field on the

General

tab in the object’s properties dialog box.

A container path for this object. The path usually consists of folder names but can also include names of other containers.

The date when this object was created.

The internal metadata type for this object.

The most recent date that this object was updated.

The metadata ID for this object.

The name of this object.

The uniform resource identifier for this object.

The metadata ID for this object’s immediate parent.

A list of the permissions to inspect for this object. If the list is blank, then all permissions that are applicable to this type of object are inspected.

The public metadata type for this object.

Table 10.3

work.mdsecds _pconds (Contains Permission Condition Expressions)

Column Name

Condition

IdentityName

Column Contents

The expression that limits this grant.

The name of this user or group.

120 Additional Resources for Building Authorization Data Sets

4 Chapter 10

Column Name

IdentityType

ObjUri

Permission

Column Contents

Person

, IdentityGroup, or Role.

The uniform resource identifier for this object.

The name of this permission (for example, Read).

Table 10.4

work.mdsecds_permsw (Contains Permissions Data Transformed to Wide Format)

Column Name

IdentityDispName

IdentityName

IdentityType

ObjName

ObjUri

(permissions)

Column Contents

The display name of this user or group (or the name if there is no display name).

The name of this user or group.

Person

, IdentityGroup, or Role.

The name of this object.

The uniform resource identifier for this object.

Table 10.5

work.mdsecds _permsl (Contains Permissions Data in Original Long Format)

Column Name

Authorization

Conditionflg

IdentityDispName

IdentityName

IdentityType

ObjName

ObjUri

Permission

Column Contents

A value that indicates where this permission is granted or denied for this identity. The type of setting (explicit, ACT, or indirect) is also indicated.

A value that indicates whether this permission setting is conditional. The value is either blank (no condition) or * (condition applies and is written to the pconds table).

The display name of this user or group (or the name if there is no display name).

The name of this user or group.

Person

, IdentityGroup, or Role.

The name of this object.

The uniform resource identifier for this object.

The name of this permission.

Additional Resources for Building Authorization Data Sets

You can choose to directly use the underlying report macros instead of using only

%MDSECDS (which is the standard approach to building authorization data sets).

However, the underlying macros don’t offer any unique inclusion or exclusion parameters. The following figure introduces the underlying macros. In the figure, arrow direction indicates input to and output from each underlying macro.

Security Report Macros

4 Additional Resources for Building Authorization Data Sets

121

Figure 10.1

Underlying Security Report Macros

Metadata Repository

Which folder?

Which objects?

%MDSEC

work.mdsecds_

objs

Which permissions?

Which identities?

%MDSEC

work.mdsecds_

permsl

work.mdsecds_

pconds

%MDSEC

work.mdsecds_

permsw

%MDSEC

work.mdsecds_

join

The numbers in the preceding figure correspond to these activities:

%MDSECGO extracts information for a specified set of objects. You specify one folder and indicate whether to include subdirectories. You can also provide a list of object types to include and filter the data set by attribute value.

Note:

The same level of control is provided by using %MDSECDS on its own.

For every object in a specified data set, %MDSECGP gets effective permission settings for a specified set of identities and permissions.

Note:

This is the point at which using the underlying macros creates an opportunity for you to define a subset of the objs data set.

%MDSECTR transforms the extracted data set from a long format (a separate row for each permission) to a wide format (all permissions in the same row).

%MDSECVW creates a joined view or data set that can be used for reporting.

The following table introduces a few utility macros that can be useful in security reporting:

122 Additional Resources for Building Authorization Data Sets

4 Chapter 10

Table 10.6

Utility Macros for Security Reporting

Utility Macro

%MDUTYPED

%MDUGFLDR

Description

Extracts information about top-level metadata objects or locates templates for a particular object type.

Returns the object ID for a specified folder.