SAS 9 Refresher Series: Metadata-based Authorization
This is part of a series on refreshing knowledge of SAS 9 Administration topics. You may find the other posts in this larger series here: SAS 9 Administration Refresher Series - SAS Support Communities
Authorization in SAS 9 determines which users have access to various resources. In part one of this security discussion, I’ll cover an overview of Metadata-based Authorization and how it can be used to control access to content. Part two will discuss using roles and capabilities to grant access to functionality.
Overview of Metadata Security
Setting security in metadata occurs together with user management. With defined user identities in metadata, we can apply authorization to control access to content those users will access and audit their activity.
This metadata-based authorization layer acts like a blanket that is draped over the underlying host and other physical resources, supplementing their existing protections. When a user attempts to gain access to those underlying resources, they must have sufficient access in all these relevant layers.
Access controls are target object-oriented: set on a specific object and set a permission for a specific identity.
Do I want to keep the cats out of the fridge? I secure access at the fridge instead of going to the cats and asking them not to eat the food. Similarly, in SAS 9: I go to a metadata object to grant or prohibit access to the identities who want to make use of that resource.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
Or, alternatively:
Levels of Granularity
In metadata security, permissions are set at different levels in the hierarchy of metadata objects. At the repository-wide level, the Default ACT (Access-Control Template) applies permissions to all objects in the metadata repository. At the object-level, an administrator can set permissions to almost any metadata object in SAS 9. Without going into an exhaustive list of all 160+ types of metadata, you can enforce access to server definitions, data definitions, stored processes, tables, folder content, and more. At a fine-grained level, permission conditions can be specified to control access to subsets of data within a resource.
Access Control Templates are ways paste or set the same permissions for the same identities on multiple objects, like a stamp that pastes out the same permission settings in multiple places. After setting ACTs, a modification to the ACT pattern applies those same permissions in all the places where the pattern was deployed, making it easy to modify groups of permissions if you use Access Control Templates.
Permissions
In metadata security, permission availability may vary by metadata object. On all objects you will find ReadMetadata and WriteMetadata permissions.
| ReadMetadata (RM) | Controls the visibility of this metadata object. |
| WriteMetadata (WM) | Controls the ability to modify (or delete) this metadata object. |
On folders, you will find WriteMemberMetadata.
| WriteMemberMetadata (WMM) | These permission settings become WriteMetadata settings on objects inside this metadata folder, allowing this parent folder to have different permissions than objects it contains. |
On servers and spawners, you will find Administer.
| Administer (A) |
On Identities, you will find ManageMemberMetadata and ManageCredentialsMetadata.
| ManageMemberMetadata (MMM) | Change the membership a group or role. |
| ManageCredentialsMetadata (MCM) | Modify external accounts and credentials of a user or group. |
On data, these permissions will apply: Read, Write, Create, and Delete. Typically, these will be set on a folder that contains the library and data, to let the permissions inherit down to all the items in the folder. Reminder that these permissions only are enforceable through metadata LIBNAME connections.
| Read (R) | See the data contents |
| Write (W) | Update or change the data |
| Create (C) | Add to the data |
| Delete (D) | Remove data |
Relationship Networks and Precedence of Permissions
The relative precedence of each access control is based on where it is placed, whom it is assigned, and how it is applied. When trying to figure precedence out, remember “Where, Who, and How”.
Where (Object inheritance): The evaluation process first looks at the target object.
Who (Identity hierarchy): On that object, are there any access controls that reference the user or a group they are in?
How (Access Control precedence): Are there any conflicts that arise here due to how the access control is applied (via direct control, indirect control, or access control template?)
If no direct controls are applied on this object, the evaluation process reassesses at the next object up in the hierarchy.
I hope this helps, thanks for reading. Stay tuned for part two, where we revisit capabilities.
Find more articles from SAS Global Enablement and Learning here.
