Best Practices for Metadata-Bound Libraries

The following list reviews key guidelines and recommendations that help you minimize administrative effort in setting up and maintaining metadata-bound libraries.
  • Use SAS (not host commands) for management of physical data. Using host commands doesn’t compromise security, but it can decrease clarity and create noise (warnings) in the audit logs. See Security Impact of Moving Tables.
    Note: An exception to this guideline is that using a host copy command to back up or restore physical data to the same directory is not problematic.
  • Within the /System/Secured Libraries folder in metadata, open up access only as necessary. In particular, grant metadata Write access (the WriteMetadata or WriteMemberMetadata permissions) to only administrators that should be able to alter access to the metadata-bound data.
  • After you bind libraries to metadata, review the metadata-layer permissions on the generated secured library objects and secured table objects, and adjust access if needed. For example, you can use SAS Management Console to add users or groups to a secured table’s Authorization tab, and grant (or deny) the Select permission (to manage Read access to the data).
  • If you use the metadata promotion tools (for example, to create separate deployments for development, test, and production environments), maintain a separate copy of your physical data for each environment. The alternative, pointing multiple metadata servers at the same physical data, is supported but introduces significantly more complexity. For more information about promoting secured library objects, secured table objects, and secured data folders, see “Promotion Details for Specific Object Types” in Chapter 21 of SAS Intelligence Platform: System Administration Guide.
  • Create or modify a metadata-bound library at a time when the physical data is not being accessed by other users. If the physical data is in use, some AUTHLIB procedure actions on open tables might fail. Interactions with a libref that was established before a library is bound are as follows:
    • For an existing physical table, the pre-established libref is subject to security that is implemented in the subsequent statement. Access that occurs in these circumstances causes a message to be written to the log. The message explains that the physical table is in a library that does not have a secured library location.
    • For a new physical table, the pre-established libref is not subject to security that is implemented through the subsequent statement, and the new table is not bound to a secured table object.
  • Ensure that all physical tables within a metadata-bound library are protected by that library. This standard, default state maximizes clarity. Special circumstances (for example, a table that has a different, pre-existing password) can result in a mixed state (for example, one of the tables within a metadata-bound library is not secured). You can use the REPORT statement to verify that this guideline is met.
  • Ensure that all physical tables that are protected by a particular metadata-bound library remain within that library (directory). This standard, default state maximizes clarity and is essential for REMOVE statements to be fully effective. Special circumstances (for example, a table that is host-copied to another directory) can prevent a REMOVE statement from unbinding the relocated data set.
  • If you bind data that users are accustomed to accessing directly, inform those users that they must establish a connection to the metadata server before they can assign a libref against a metadata-bound library.
  • In your metadata backup strategy, remember to consider your secured data folders, secured library objects, and secured table objects. See Chapter 11, “Best Practices for Backing Up and Restoring Your SAS Content,” in SAS Intelligence Platform: System Administration Guide.
  • Use the LIBNAME option AUTHADMIN=YES when you are repairing any inconsistencies between physical data and its corresponding secured library and secured table objects in metadata. Do not use AUTHADMIN=YES in other circumstances.