Example: Business Unit Separation :: SAS(R) 9.3 Intelligence Platform: Security Administration Guide

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 a partial group and folder structure.

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

Folder	Direct Controls
ACTs	Explicit Grants
DemoBranch	Protect LimitData
DivisionA	Hide	GroupA: +RM, +R
Project1		GroupA: +WMM
Project2		GroupA: +WMM

Here are some details 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.
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.