Best Practices

General Guidelines

The following list provides general guidelines for implementing metadata-bound libraries:

Use SAS (not host commands) for management of physical data. Using host commands does not 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 the WriteMetadata and WriteMemberMetadata permissions to only administrators that should be able to change 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 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 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.
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 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.

Avoiding Mixed States

Binding data to metadata is a library-level feature. In general, all tables within a metadata-bound library are protected by that library and share the library’s password.

To establish and maintain a best practice state that minimizes complexity:

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 bound to that library). To verify that this guideline is met, validate the library.
Ensure that all physical tables that are protected by a particular metadata-bound library remain within that library. This standard, default state maximizes clarity and is essential for unbind actions to be fully effective. Special circumstances (for example, a table that is host-copied to another directory) can prevent an unbind action from unbinding the relocated data set.

For example, if someone uses a host copy command to add unbound physical tables to a metadata-bound library, the added tables are not automatically bound. To bind the added physical tables, use the modify action to re-apply the password of the metadata-bound library. See Changing a Metadata-Bound Library Password.

Note: If the host-copied tables were already bound to another library, you must first use the REPAIR DELETE LOCATION statement of the AUTHLIB procedure to remove that binding. See REPAIR Statement. After you remove the original binding, you can use the modify action to re-apply the password of the library in which the tables are currently located.