As we have seen my previous post "Seeing SAS data through metadata", there is a fundamental difference between accessing a SAS library using a physical reference or a metadata reference to that library. By now, you should now be an expert on the nuances of physical references to SAS data versus metadata references! This time, we are going to dive into one of the more subtle aspects of metadata library management: pre-assigned libraries.
Why should you pre-assign SAS libraries?
As outlined in the SAS 9.3 Intelligence Platform: Data Administration Guide, there are two ways you can make sure that your server is aware of your library reference:
- pre-assigning the library
- letting the client application define the library reference
Even if you use a LIBNAME statement in your program, it is useful to register SAS libraries and tables in SAS metadata so that they can be used by some of the SAS clients (for example, SAS Data Integration Studio). We saw this demonstrated in our last article when we assigned a libref through a LIBNAME statement versus one assigned in SAS metadata. Different clients may assign libraries differently, such as SAS Data Integration Studio or SAS OLAP Cube Studio where the library can be automatically generated based on the metadata.
When you pre-assign a library, you are making explicit which engine will be used to control the library (such as BASE or ORACLE). Pre-assigning the library has a number of benefits:
- Pre-assigning librefs helps maintain consistency across users and applications
- Libraries are always available to the server, regardless of how the program is run (batch versus interactive)
- Libraries are easier to migrate to new storage since the physical location can be abstracted from the user
- Pre-assigning libraries makes it easier for developers to eliminate redundant code (for example, not having to manage library references in stored processes)
As discussed last time, if you don’t pre-assign our library and try to use that library in SAS Enterprise Guide, you get an error.
PROC Print data=metaref.postassessments; run; ERROR: Libname METAREF is not assigned.
As a result, you are forced to right click on the library in SAS Enterprise Guide and select “Assign” manually each time you start a new session.
To see this libref as “Assigned” when connecting to the server, you would need to pre-assign the library. This action tells SAS to run the assignment code on the server whenever the server is started. If you select “Library is Pre-assigned” in the Advanced options (SAS Management Console→Data Library→ Manager→<Library> Properties), you see three Pre-Assignment Types listed:
- By native library engine
- By metadata library engine
- By external configuration
Understanding three methods for pre-assigning libraries
So which of the three options are right for your libraries? Here is a nice graphic and description of what really happens behind the scenes when you access a library governed by one of these processes.
Key to understanding these choices is to knowing the difference between the Metadata Library Engine method (option 2 above) versus the other two approaches that use the native engine.
- In the case of the native engine, the system does not check the SAS metadata to see if the user has read access on the table; however, it does check the physical security and whether the user has permission to ReadMetadata. When you use a native engine, the data-level authorizations of Read, Write, Create, and Delete are not checked.
- If you want to use the metadata authorization layer to control Read, Write, Create, and Delete permissions, then you must pre-assign the library and use the Metadata Library Engine method. But remember, operating system level file permissions should always be considered whether you use the SAS Metadata Libname Engine or the underlying native engine.
- Additionally, as we have noted, it is not always efficient to pre-assign every library that you might want to use. (In fact, a little birdie reminded me that too much of good thing may affect performance.) You should determine which libraries will actually be needed before you choose to pre-assign them. You should also set READMETADATA privileges to limit which libraries a group of users sees, as not everyone needs every library.
- One related area you may want to consider is the notion of read-only access. You will note that in the properties for a library, you have the option of specifying the library as READONLY. This capability augments the metadata permissions on the library or table in the fact that it eliminates the possibility of anyone writing to or destroying elements contained in the library – even if they have metadata permissions to do so.
In the discussion that follows, I will focus only on the mainstream servers (Workspace Servers, Pooled Workspace Servers, Stored Process Servers, SAS/SHARE servers and OLAP servers) as these servers automatically read metadata when they start and assign the libraries. You will have to edit the server configuration files if you want these to be read by other servers such as SAS/CONNECT, SAS Data Step Batch Server or SAS/IntrNet.
So let’s summarize the three assignment options in SAS metadata and explore how each one works and why we would select one over another.
By Native Library Engine
When you select the native library engine as the Pre-Assignment Type, you will notice that, in SAS Enterprise Guide, the client immediately has access to the library and the defined metadata tables.
The library is assigned when the SAS session starts and referenced through a SAS System Option called METAAUTORESOURCES. SAS uses the library engine defined for the library in SAS metadata. As noted above, the data-level authorizations are not checked in the SAS metadata. To illustrate this, we will set the metadata permissions in this example to read only.
Then we will try to replace the table.
Here, you notice that despite the metadata permissions of Read and ReadMetadata, the user was able to delete the dataset. As we mentioned above, if the native engine is used to access the table, then metadata permissions are not evaluated.
Note: For SAS 9.3, SAS has added a feature called metadata-bound libraries, which cannot be overridden. Metadata-bound libraries offer better protection than do other metadata-based approaches to access control because the enforcement begins with the physical data. The enforcement occurs regardless of how the user requests access to the data (metadata clients such as SAS Web Report Studio or direct (through a LIBNAME statement submitted from SAS Enterprise Guide). For more information, see the documentation for metadata-bound libraries.
By Metadata Library Engine
When you select the Metadata Library Engine as the Pre-Assignment Type, the library is similarly assigned through METAAUTORESOURCES options; however, this option uses the Metadata Library Engine that ensures access controls that are placed on the library and its tables and columns are enforced. Here, we submit a simple DATA step that tries to replace an existing dataset. Note that our metadata permissions did what they were supposed to do.
By External Configuration
The third and final option for pre-assigning libraries is to use an external definition or an autoexec file. This method essentially makes the library available to client applications but moves the code out of the user interface to an external file. This option is particularly useful if you want to manage your configuration outside of SAS metadata or share the configuration among multiple services such as SAS/Connect.
Four questions to help choose the best method
Since I am a visual thinker, I also thought it might helpful to show these comparisons in a flow chart. Admittedly, this is a simple set of decisions, but the chart should help you decide which pre-assigned library option might be best for your case.
Hopefully, this post was a useful discussion, and you know a bit more about what it means to pre-assign libraries and how the various options affect whether users can read or both read and write data.