Permissions on Folders

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.

Demonstration: Folder and Group Structure

[Demonstration: Folder and Group Structure]

To set this up, complete these steps:

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:
1. Right-click User Manager and select New Group.
2. On the General tab, enter the name GroupA. Click OK.
3. Repeat steps 2a-b to create a group named GroupB.
Create two temporary users:
1. Right-click User Manager and select New User.
2. On the General tab, enter the name userA.
3. On the Groups and Roles tab, move GroupA to the Member of list box.
4. 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.
5. Notice that the new account now appears at the bottom of the Accounts tab. Click OK to save the new user.
6. Repeat steps 3a-e to create userB (who should be in GroupB).
Create the folder structure:
1. On the Folders tab, right-click the root folder and select New Folder. Create a new folder named DemoBranch.
2. Add subfolders under DemoBranch until it looks like the structure in the preceding display.
Protect the top of your custom branch:
1. Right-click DemoBranch and select Properties.
2. On the Authorization tab, click Access Control Templates.
3. 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.
4. 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:
1. Apply the Hide ACT.
2. Add GroupA to the Authorization tab and give them explicit grants of ReadMetadata, WriteMemberMetadata, and Read permissions.
On each project folder below DivisionA:
1. Apply the Protect ACT.
2. 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:

Demonstration: Permission Settings
Folder	Protections
Folder	Baseline ACTs	Supplemental Grants
DemoBranch	Protect LimitData
DivisionA	Hide	GroupA: +RM, +WMM, +R
Project1	Protect	GroupA: +WMM
Project2	Protect	GroupA: +WMM

Test the protections:
1. 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.
2. 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 (under System Users).

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.
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 [icon] . By default, the schema is in the SAS Folders/Shared Data/ SASApp - OLAP Schema folder. [cautionend]

The intent of this simple example is to introduce use of the baseline ACTs and give you an opportunity to experiment. The following topics describe variations and provide guidelines to help you design an implementation that is appropriate for your environment and goals.

	Use and Enforcement of Each Permission
	Key Points About the Baseline ACT Approach
	Variation 1: Add Subgroups, Designate Content Creators
	Variation 2: Add Functional Separation
	Further Considerations for Permissions on Folders