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.