Authorization Model

Permissions by Item

	Common Access Adjustments By Item
	Permissions Tips: Selected Items in the Folder Tree
	Permissions Tips: Selected Items Outside the Folder Tree

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:

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).

Common Access Adjustments By Item

[access categories]

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

Permissions Tips: Selected Items in the Folder Tree
Root folder	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.
Folder	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. 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 Authorization tab is relevant for every item in that folder. 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 Permissions on Folders and Using WriteMetadata and WriteMemberMetadata Permissions.
Information map	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: 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. 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.
Stored process	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.
Channel	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 Publishing 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 Publishing Subscribers Content Subscribers folder). See Using WriteMetadata and WriteMemberMetadata Permissions.
Dashboard	The permissions model for dashboards and their related items (indicators, data models, and ranges) has several unique aspects. See Administering SAS BI Dashboard in the SAS Intelligence Platform: Web Application Administration Guide.
Schema	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.
Cube	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.
Cube component	To access the Authorization tab for an OLAP dimension, measure, level, or hierarchy, navigate on the Plug-ins tab under Authorization Manager Resource Management By Location <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.
Library	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.
Table	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).
Column	To access a column's Authorization tab, navigate on the Plug-ins tab under Authorization Manager Resource Management By Location <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.

Permissions Tips: Selected Items Outside the Folder Tree
Repository	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 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.
Application server	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 Permissions on Servers.
Logical server	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.
Identity	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.
ACT	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 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.

	Use and Enforcement of Each Permission
	Permissions by Task
	The Authorization Tab