BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
Fluorite | Level 6

I would like to understand if there's a good case for using metadata bound libraries in general and the following set-up in particular:


  • SAS 9.4 on a Linux server
  • Access to the server only through EG and SAS Studio
  • No shell or XCMD access for users
  • Data is primarily sorted on a database server, users will take cuts of data and store on SAS server for further analysis
  • Users are organized in relatively large number of groups that work on one or more projects. Few users are in more than one group
  • A group should not have access to other groups' SAS data and analysis output.

Without metadata bound libraries (MLB), (almost) all we have to do is

  1. Provision users in SAS and on Linux
  2. Provision Linux groups and populate with users
  3. Create respective data and output folders on the Linux for each group with appropriate permissions

In this case, the users of each group can create folders to organize their data sets and results however they wish. Essentially the SAS server storage space is used similar to a file system with only file system security in place.


With MLB, the following needs to be done:

  1. Provision users in SAS and on Linux
  2. Provision Linux groups and populate with users
  3. Create respective data and output folders on the Linux for each group with appropriate permissions
  4. Create SAS groups and populate with users
  5. Create SAS metadata folders and secure them based on the SAS groups
  6. Create SAS Secured Libraries with encryption
  7. Provision secured libraries to each group with appropriate permissions (create table, etc)
  8. Create and assign libraries that correspond to the secured libraries
  9. Do some magic with symbolic links so that users are not able to navigate the data folder, and not able to create sub-folders there, essentially preventing them to store data unencrypted
  10. Monitor the output folders to make sure SAS data files are not stored there

In this case, users are not able to freely organize their data tables in folders, they only have a library to store their data. This means they have to adopt naming convention for their tables in the library and be extra careful not to overwrite each others tables. Essentially, the SAS server storage is used similar to a database schema. Administrators still need to monitor output folders to make sure data files are not stored there unencrypted. I understand the additional benefit of encryption at rest, but this seems to protect the data mainly from storage administrators. In case the SAS server is compromised, I don't think MLB provides any additional benefits as the encryption keys are maintained in metadata and someone who has come this far to gain access to the server, probably could figure out how to unencrypt the data as well.


Maybe I am missing the point of MLB. What do you think?



Accepted Solutions
SAS Employee

There has been a lot of good discussion on this topic thus far, but I've seen some possible confusion that I wanted to clarify. Metadata-bound libraries are a unique configuration that are different from libraries simply defined within the metadata. You can define libraries in the metadata for various types of data sources, such as SAS data sets or external database data. However, metadata-bound libraries (MBLs) are only applicable to SAS data sets and associated SAS indexes.

When you define a metadata-bound library, you run PROC AUTHLIB code to password-protect and physically bind all data sets in a defined path to metadata. With this approach, the data set password gets stored in metadata and you effectively lock down direct access to SAS data via a BASE engine libname statement and enforce metadata permissions for access to the SAS data. Users don't need to supply the password for data access, they instead just require a metadata aware SAS session and metadata permission to access the data.

If you want to encrypt the data at rest, then you would also use the REQUIRE_ENCRYPTION, ENCRYPT, and ENCRYPTKEY options on the PROC AUTHLIB statement to enforce encryption of the MBL data. See the SAS 9.4 Guide to Metadata-Bound Libraries for more information PROC AUTHLIB.

SAS Management Console has a user interface for defining MBLs, which effectively just generates and executes PROC AUTHLIB code behind the scenes. However, I typically like to write the code myself and run it outside of SAS Management Console just to clearly define and document the code options used.

As an FYI, I am a member of a SAS Consulting team that works with customers on architecture, administration, and security topics. In our experience, we have primarily only utilized Metadata-bound libraries for implementations which require encryption of SAS data. There is definite administration overhead in implementing MBLs, but they are the best way to seamlessly enforce encryption of SAS data. I always inform our customers that SAS data set encryption also requires defined user and administration processes in order to monitor and enforce the use of MBLs. Deepali Rai is another SAS consultant I work with and she will actually be presenting a SAS Global Forum 2018 paper on this topic based on best practices we have learned in wo.... Look for her in Denver in April!

Angie Hedberg

View solution in original post


Is encryption of data at rest a requirement of your organisation's security policy or is there a business requirement you are satisfying by doing this? If there is no such requirement then I'd say the administration overhead of MBLs is not worth it.


In other words your need for MBLs should be driven by business requirements as the administration overhead is significant. BTW MBLs can only be accessed via SAS metadata and metadata-defined libraries so the chances of cracking the encryption independently are pretty slim.

Fluorite | Level 6
The business requirement is optimal security, i.e. the right balance of usability and security. Encryption at rest is not currently a mandatory requirement, but it may become one in the future. Even then, I don't see MLB fulfilling that requirement entirely, as we still have to watch other folders for unencrypted datasets. The set-up also has to be future proof and allow for easy integration with other SAS products and I am not sure if predefined libraries are needed for products like SAS VA (no experience with those). Some of our users are heavy SAS desktop users who are used to organizing data, scripts, and results for their projects in folders and MLB forces them to have data in libraries and obviously they don't like it.

IMHO I'd wait until the requirement becomes mandatory, then implement it in your next SAS upgrade. BTW with MBLs users cannot independently store their SAS data in other locations as they can no longer assign LIBNAMEs in code - all LIBNAMEs have to be done in SAS Management Console and stored in SAS metadata.

Fluorite | Level 6
And I noticed I have been using MLB instead of MBL 🙂
Fluorite | Level 6
What would prevent the users to create a libref to a location that they have access to?
Super User

I haven't explored this much but as a programmer, I don't like the idea of metadata bound libraries.  I feel like they shift the balance of power too far toward the administrators.


If you've got a bunch of experienced SAS programmers, they are used to writing their own libname statements to access SAS datasets (and relational databases, and flat files and .... )  For this group, centrally defined metadata libraries may be a nice convenience, but with a metadata bound library you say "the only way to read this SAS dataset is with a (the?) metadata library", that's annoying to me.  I want to write my own libname statements.


As you say, even with metadata security you still need OS-level security.  So metadata bound libraries don't save you from designing the OS-level security.


For the (smallish) group of folks working on our main server, we have a fairly basic metadata security model.  We have a metadata group for each project, and that determines who can see which metadata objects.  For most of the data sources (SAS datasets and databases), we rely on OS security.  I typically don't even define a data source as a metadata object unless I need to use it to define some other metadata object (e.g. stored process prompt).  Most of the SAS code that I write on our BI server would also run fine on PC SAS, because the code itself doesn't reference metadata objects.  It's worked well for me, and made it easier to move back and forth between PC SAS, and server SAS (mostly coding DI jobs and stored processes for web stuff).


I suppose if we had a more sophisticated metadata security model, then the idea of metadata bound libraries would be a benefit.  Because it would prevent people from circumventing our fancy metadata security.  And there are things you can do with metadata security (I think row-level and column-level access) which you can't do with OS security of a SAS dataset.  I definitely see value in metadata security layered on top of OS security.  But if you aren't relying much on metadata security, then I wouldn't think metadata bound libraries would offer much.


But I'm just a user with a biased perspective, not an admin.  Would be interested to hear the pro-MBL argument.  When I think metadata administration, my first thought is @MichelleHomesand @PaulHomes.  Perhaps they'll jump in.

BASUG is hosting free webinars Next up: Mike Sale presenting Data Warehousing with SAS April 10 at noon ET. Register now at the Boston Area SAS Users Group event page:

This would only be possible if the users had access to SAS Management Console and they had administrator rights to create data sources. As already mentioned if you create a MBL environment then you can't create SAS libraries in code using LIBNAME statements. 

Fluorite | Level 6
This works perfectly fine and stores data set in home folder of the user.
libname mylib base '~/';
proc freq;

Sorry, I was under the impression that you could enforce all of your permanent SAS libraries to be metadata-bound but after checking the documentation I don't think that is the case. You can have a mix of MBLs and non-MBLs in your SAS environment.

Community Manager

One of the main use cases for MBLs is to prevent unauthorized users from assigning a libname to a path they should not, and then getting access to data.  MBLs ensure that the user permissions are granted in metadata, despite permitted file system access.


In your scenario, if your Linux groups are enforcing proper access to the proper file system folders for the proper people, then there isn't a risk that a rogue user can assign a libname to a folder they aren't supposed to see...right?  So I don't think it buys you anything.  And your source database has its own security layer (assuming each user has their own credentials for access), so no need for an additional layer there.


And yes, the data in MBLs is encrypted to prevent snooping by those who would circumvent the metadata approach -- but the encryption might not conform to specific "at rest" encryption requirements you might have in your policies.  You would have to compare your policies -- if specific techniques are stated -- with the MBL documentation for admins.

It's time to register for SAS Innovate! Join your SAS user peers in Las Vegas on April 16-19 2024.
Rhodochrosite | Level 12

As others have already suggested, obviously you should only go to the effort to creating and maintaining additional protections that are proportionate to the sensitivity of the data and the risk of inappropriate access. If your content is already adequately protected, according to organisational requirements, then why add the complexity of SAS Metadata-Bound Libraries (MBLs)?


You may have already seen them but just in case, and for the benefit of others who may be following this thread, some good documentation references that discuss the appropriateness and benefits of MBLs include the following:


To try to provide another perspective I will pose some questions/scenarios where MBLs can provide benefits. These may not apply to your situation but may help show some situations where MBLs can help. If these examples don't help directly then perhaps they might still explain why it can sometimes be useful to have the additional flexibility they can provide.


Securing content through multiple authorisation layers (that have both common and unique features) can be done for several reasons e.g.

  1. defence-in-depth - redundant layers may provide protections when other layers fail due to accidental or deliberate changes
  2. completeness/flexibility - taking advantage of features not available in preceding layers e.g. row/column level permissions
  3. user experience consistency e.g. don't show users content they wouldn't have access to in preceding layers


A question I often see is why use metadata permissions (and perhaps MBLs) when operating system permissions can be used?


Leaving aside the defence-in-depth argument, sometimes it is not possible to rely purely on file system permissions. Consider SAS tables being accessed within the context of a SAS Stored Process Server, SAS Pooled Workspace Server, or SAS Workspace Server configured for SAS Token Authentication. The operating system identity is the same for all users - a service identity. In this case SAS metadata authorisation allows for finer level access controls than is possible with file system access controls. In this situation SAS metadata access controls allow you to control access for the requesting SAS identity (preferably through SAS metadata groups) where file system access controls cannot.


Why use metadata permissions when people can just use the libname-loophole (as it is often called)?


If you have configured SAS metadata access controls for SAS tables then there is the potential for SAS coders to bypass the metadata permissions by coding a base engine libname statement to get direct access to the data. If your file system access controls mirror your SAS metadata access controls then this may not be a concern, but if they need to be different, perhaps due to service identity use or row level permissions, then MBLs allow you to prevent this bypassed-access and enforce the additional use of the metadata authorisation layer.


How do I ensure row/column level permissions are enforced?


Some organisations have requirements to limit access to subsets of data based on filter conditions based on the requesting identity. In the past this has been done with SAS information maps over the tops of SAS tables but then you had to consider 1) people bypassing the information maps and going directly to the tables and 2) information maps were not as widely accessible as SAS tables. MBLs allow permission conditions to be applied at the SAS table level. This is as low as you can go since these types of access controls cannot be done at the file system level.


SAS tables in MBLs also have a wider range of metadata permission support than SAS tables in traditional libraries. Imagine you have a custom application requirement where users can add new data to a table but not modify or delete that data once added. By using a MBL and ensuring their effective permissions are +S, +I, -D, -U then you constrain them to view and add data but not delete or update it. If that person could gain file system access to the underlying table then adding encryption prevents them from copying the table to another location, modifying the data outside of the MBL and moving it back again.


Whilst I think that the responses so far have probably already answered the questions for your scenario, I hope this has helped add some general insight on where MBLs can be useful or even required.


Fluorite | Level 6

Thanks everyone for your comments.



You mention a really good point about different server contexts. In our implementation we have disabled the ability to use stored procedures due to security concerns, i.e. users being able to invoke stored procedures that run under the context of the service account and potentially gain access to data that they normally don't have access to. I think we should investigate more how MBL can prevent such scenarios.


Apart from that, we also see a potential benefit in MBL with regards to data management, which is reducing duplication and proliferation of data sets. The users may need same cut of data for various projects, and using MBLs, provides more visibility to what is already available which could lead to less storage consumption (premium storage is of course not cheap) and a bit more collaboration among them. However as @Quentin alluded to, we are sensing some resistance from the experienced SAS programmers.


All that said, the architecture of MBL is a bit flawed IMHO which despite adding extra layers of complexity, still allows for non-compliance. I see it as SAS base engine trying really hard to act like a RDBMs engine, but still carrying the legacy of a file based database system with itself.


Lapis Lazuli | Level 10

Very interesting discussion, thanks for posting Smiley Very Happy !


Per se, MBL cannot guarantee full security unless you also assign some security at filesystem level (POSIX or NTFS based, in practice). This means, as @PaulHomes said, that perhaps only when strong encryption at rest is required, MBL own requirements prove beneficial all things considered. 


This is why I'll recommend to balance MBL with another set of security tools, SAS Locked Down mode, which is very practical when security rules must be tightened without spending too much time upon security issues. This might be somewhat difficult to enable with SAS workspace sessions when the end users are used to create everything manually (which is not a good practice in general, tells me Mordac).




If you combined LOCKDOWN with the locked down folders pointing only at  MBL enabled folders would that prevent users creating their own permanent SAS libraries outside of MBL?  I'm interested in understanding how they would work together..


BTW, enjoying this great discussion Smiley Happy

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 33 replies
  • 11 in conversation