Variation 2: 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 divisional affiliations. 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 a partial group and folder structure.
Group and Folder Structure
Group and Folder Structure
The following table lists the protections for the first six folders:
Functional Separation
Folder
Direct Controls
ACTs
Explicit Grants
icon DemoBranch
icon Protect
icon LimitData
icon DivisionA
icon Hide
icon Managers: +RM, +R
icon GroupA: +RM, +R
icon data definitions
icon Protect1
icon Data Admins: +WMM
icon information maps
icon Protect1
icon Map Creators: +WMM
icon reports
icon Protect1
icon Report Creators: +WMM
icon stored processes
icon Protect1
icon Map Creators: +WMM
icon Report Creators: +WMM
1You 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.