The following figure
depicts the authorization model for a traditional table and a metadata-bound
table. In both cases, UserA references the target data directly (for
example, through a LIBNAME statement) and UserB requests the target
data through a client that uses metadata to locate data (for example,
SAS Web Report Studio).
The preceding figure
depicts the following key difference:
-
When accessing a traditional table,
a user can bypass metadata-layer controls by making a direct request.
-
When accessing a metadata-bound
table, a user cannot completely bypass metadata-layer controls. Even
on a direct request, UserA is always subject to a metadata-layer permissions
check before accessing SAS data from SAS.
For the metadata-bound
table, the upwards-facing arrows are caused by the physical data’s
security binding. For each metadata-bound table, information within
the table header identifies a corresponding metadata object (a secured
table object). Metadata-layer permissions on each secured table object
affect access from SAS to the corresponding physical table.
For the metadata-bound
table, UserB is subject to two metadata-layer authorization checks
against two different metadata objects.
-
The first check is against a traditional
table object (for example, verifying that UserB has the ReadMetadata
permission).
-
The second check is against a secured
table object (for example, verifying that UserB has the Select permission).
Here are some additional
details about the preceding figure:
-
The requesting users do not supply
library or table passwords.
-
The metadata-layer authorization
checks are against the metadata identity of the requesting user. The
host-layer authorization checks are against the identity of the SAS
process that retrieves the data.
-
The figure addresses access to
SAS data from SAS, not interaction through host commands.
-
The figure is conceptual, simplified,
and abstracted. It is not intended as a detailed technical specification.