Review: Key Points about Authorization

In order to effectively use the metadata authorization layer, you must understand the following points:
  • Metadata layer permissions supplement protections from the host environment and other systems. Across authorization layers, protections are cumulative. In order to perform a task, a user must have sufficient access in all applicable layers.
  • The displayed effective permissions are a calculation of the net impact of all applicable permission settings in the metadata layer. However, the display doesn't reflect access in other layers such as the operating system.
  • Setting permissions is an object-centric activity. To define permissions for someone, do not begin by finding that person's user definition. Instead, begin by navigating to an object that you want to protect or make available.
  • Explicit and ACT controls on an object (such as a report) always have priority over controls on the object's parent (such as a folder). For example, if a report has an explicit denial for PUBLIC and the report's folder has an explicit grant for you, the result is a denial for you. The direct denial for PUBLIC blocks access to the report (for all restricted users), unless you offset the direct denial by adding direct grants on the report.
  • In a user definition, the displayed permission settings have no effect on what the user can see or do. Those controls determine who can update or delete the user definition itself.
  • Only the ReadMetadata and WriteMetadata permissions are universally relevant and enforced.
  • The authorization layer that SAS provides supports very specific settings. For example, on ReportA, grant the ReadMetadata permission to UserA. However, for simplicity, it is preferable to set permissions at a less granular level whenever possible. The recommended approach is to create a folder structure and set permissions so that each folder offers appropriate group-level access to its contents. For example, on FolderA, grant the ReadMetadata permission to GroupA.
  • After you add a broad denial, review the impact that this has on everyone else. For example, if the only setting on an object is an explicit PUBLIC denial, that denial blocks access for everyone (other than unrestricted users). To offset the denial, add one or more selective explicit (or ACT) grants.
  • Before you deny the ReadMetadata permission on a folder, consider the navigational consequences. Without ReadMetadata permission on a folder, you can't browse to objects beneath that folder. Users need a clear path of grants of ReadMetadata permission in order to browse to the content that they use.