Permissions on Folders

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. [cautionend]

The following figure depicts goals and group structure.

Variation 2: Folder and Group Structure

[Variation 2: Folder and Group Structure]

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

Variation 2a: Permission Settings (functional separation)
Folder	Protections
Folder	Baseline ACTs	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.

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.