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.