Depiction of a Metadata-Bound Library

The following figure depicts the metadata objects and physical security information that are generated when you bind a physical library to metadata. The "Before" section shows the initial state and the "After" section shows the security location information, bindings, and metadata objects that are generated by the CREATE statement of the AUTHLIB procedure.

Here are some key points about the "After" section of the preceding figure:

The physical data includes references to corresponding objects within a SAS metadata repository.
- For a physical library, the security information consists of a subdirectory and file. The corresponding metadata object is called a secured library object. In the figure, seclib is the secured library object that corresponds to the physical metadata-bound library called sensitive data.
  
  Note: On z/OS, the security information for a UNIX file system (UFS) library is stored as described in the preceding figure. However, the security information for a z/OS direct-access bound library is instead stored within the bound library data set itself. For this reason, z/OS sites that choose to use metadata-bound libraries might prefer the z/OS direct-access bound library implementation to the UFS library implementation. z/OS sequential-access bound libraries cannot be bound to metadata.
- For a physical table, the security information consists of information in the header. The corresponding metadata object is called a secured table object. In the figure, tableA and tableB are secured table objects that correspond to the physical metadata-bound tables tableA.sas7bdat and tableB.sas7bdat.
Each security binding causes all access from SAS to be subject to the requesting user’s effective metadata-layer permissions on the relevant corresponding metadata object.

Note: The figure assumes that the physical data is initially unprotected. If one of the physical tables already had a different password, the presence of that password would prevent that table from being affected by the CREATE statement. To move from that situation to a best practice state (where, for clarity, all tables within the security library are protected by that library’s bindings), use the MODIFY statement of the AUTHLIB procedure.