ACL Security Model

User Ownership of Domains and Resources

Resource ownership begins with the domain definition in the libnames.parm parameter file. Administrators can attach an OWNER= specification to any defined domain. Only the system user whose SPD Server user ID matches the OWNER= specification (and users who have special privilege) can create tables in this domain. The owner can grant other server users Read and Write permission to the domain by defining a domain ACL. If a domain definition does not contain an OWNER= specification, then any SPD Server user can create resources in the domain.
Each resource created is also tagged with the user ID and group of the user who created it. This user is referred to as the resource owner. Only the resource owner (or users with special privilege) can access a table, unless the owner grants others access through ACLs.

ACL Permissions

The following permissions can be specified in an ACL to grant universal permission to all users:
READ
grants universal Read access to the resource (read or query).
WRITE
grants universal Write access to the resource (append to or update an existing resource).
ALTER
grants universal Alter access to the resource (rename, delete, or replace a resource, and add or delete indexes associated with a table).
The following properties can be specified in an ACL to grant permissions to users in the owner’s group:
GROUPREAD
grants group Read access to the resource (read or query)
GROUPWRITE
grants group Write access to the resource (append to or update)
GROUPALTER
grants group Alter access to the resource (rename, delete, or replace a resource, and add or delete indexes associated with a table).
To grant specific users and groups permissions to a resource, resource owners can define user lists and group lists in the ACL. A user list defines either a grant (Y) or denial (N) for each of the following properties for a given user ID. The group list defines either a grant (Y) or denial (N) for each of the following properties for a given group name.
READ
grants the named user or group Read access to the resource (read or query)
WRITE
grants the named user or group Write access to the resource (append to or update)
ALTER
grants the named user or group Alter access to the resource (add, rename, delete, or replace a resource, and add or delete indexes associated with a table)
CONTROL
grants the named user or group Control access to the resource (ability to modify the resource’s ACL).
ACLs are created in PROC SPDO. Use the ADD ACL statement to create an ACL. User lists and groups lists can be added to an existing ACL using the ACL MODIFY statement.

ACL Groups

SPD Server ACL groups are similar to UNIX ACL groups. Each SPD Server user can belong to one or more groups.
SPD Server administrators can associate a given SPD Server user ID with up to 32 ACL groups, depending on how SPD Server is configured. By default, a user connects to the server with the first group defined for the user in the password database. Users can connect to SPD Server with a different group from their group list by specifying the ACLGRP= option in the SPD Server LIBNAME statement. The ACLGRP= value must match one of the groups that are defined for that user.

Granting Permissions with ACLs

An ACL permits three distinct levels of permission on a resource.
  1. First, you can grant universal permissions to users who are not in the same ACL group as the resource owner.
  2. Second, you can grant Group permissions to users who are in the same ACL group as the resource owner.
  3. Third, you can grant User permissions to a specific user ID or Group permissions to a specific group.

ACL Types

Domain ACLs

A user whose user name is specified as OWNER= on a domain can control access to his or her domain by creating a domain ACL. A domain ACL is created by specifying the /LIBNAME option when you add an ACL. The permissions defined in the domain ACL are applied whenever a server user attempts to connect to the domain. The owner must grant a user either Read or Write permission in the domain’s /LIBNAME ACL for the connection to succeed. The Read permission gives a user Read and Write permission to existing resources in the domain, based on the resource ACLs, but does not allow the user to create new resources in the domain. Write permission in the /LIBNAME ACL is necessary to allow a user to create new resources in the domain.

Domain ACLs for LIBACLINHERIT=YES Domains

When creating an ACL for a domain that specifies LIBACLINHERIT=YES, SAS recommends granting Read permission to other users only. Write permission to a LIBACLINHERIT=YES domain would allow other users to update the owner’s tables in addition to creating tables in the domain. Alter access would allow other users to add and remove columns and indexes in the owner’s tables, in addition to creating tables in the domain. To protect the integrity of the owner’s tables, neither Write nor Alter permission should be defined in an ACL for a LIBACLINHERIT=YES domain.

Resource ACLs

Users who have been granted the ability to create resources in a domain will need to create ACLs for their resources to allow other users and groups to access the resources. In PROC SPDO, the resource type for all resources except the domain ACL is indicated by using the SET ACLTYPE statement. The SET ACLTYPE statement is specified before the ADD ACL statement and other statements that act on an ACL in PROC SPDO. If you omit the SET ACLTYPE statement from an ACL request, the server will assume that the resource type is DATA.
All resources except table columns are identified in an ACL entry by using a one-part name. When a two-part name is used, it is assumed that the first part is a table name and the second part is a column name.

Generic ACLs

SPD Server supports generic ACLs to enable resource owners to define permissions for a class of resources that have a common prefix. A generic ACL is created by specifying the /GENERIC option when you add the ACL entry. Marking an ACL as generic causes the ACL to function as if an asterisk (*) wildcard was appended to the end of the ACL entry’s name. For example, if you have tables named Salesne, Salesse, Salesmw, Salessw, Salespw, and Salesnw, you could make a generic ACL entry named Sales to secure all of the tables. This wildcard behavior enables you to make a single ACL entry cover many resources instead of making separate entries for each resource.
Note: If you specify /GENERIC when you define a table-column ACL, the /GENERIC option applies to the table name, not to the column name. You cannot use wildcard characters with column names.
If you create a generic ACL for a resource that has a full name ACL, the full name ACL takes precedence. If you create multiple generic ACLs that cover the same table name, the longer generic ACL takes precedence. For example, if you have table MYTABLE and created ACL MYTABLE and generic ACL MYT*, the MYTABLE ACL takes precedence for permission checks on the table. If you create table MYTABLE, generic ACL MYT*, and generic ACL M*, the generic MYT* takes precedence for permission checks on the table.

Column ACLs

Table owners can control access to table contents at the column level by defining column ACLs. Column ACLs can be defined for individual users at the user level, or for collections of users at the group level. SPD Server enforces precedence for user and group ACL permissions: First, user ACL permissions are applied, and then group ACL restrictions are applied. User permissions override group permissions.
When you use an ACL statement to create a protected column in a table, all individual users or groups are automatically denied access to the protected column until you explicitly grant them ACL permission to access it. When you issue an ACL statement to grant or deny the contents of a table column to a single user or to a user group, the protected column automatically becomes unavailable to all other users and user groups, unless you specifically give them access to the protected column.
Consider a scenario in which a testing department hires a new member, Joe. Joe has applied for classified security clearance, but his or her security clearance level will not be certified for several weeks. All members of the department use a table called Testing that contains a column of classified information. Joe needs access to all of the Testing table except the protected column, and the rest of his or her group needs access to the whole Testing table. Here are steps to give Joe and the other members of the department the correct permissions:
  1. Submit a user-level ACL statement to restrict the secure column in table Testing from Joe.
    Joe is explicitly denied access, but because the column is now a protected entity; all other users who access the Testing table are also denied access to the column by default.
  2. Issue a group-level ACL column permission to the user group Testgroup. Explicitly grant group Testgroup access to the protected column.
    After a column is protected with ACL security, you must grant explicit permissions in order for any user (or group of users) to be able to access the column content.
  3. SPD Server reads the user-level ACL permissions first, and gives Joe access to the table Testing, but restricts him or her from the secure column.
  4. SPD Server reads the group ACL permissions and grants all of the Testgroup members access to the full table, including the secure column.
Now consider another scenario, in which John manages a group Devgroup whose members record their billable project hours and codes in a table. In that table, manager John keeps billing-rate information based on employee salaries in a protected column Rate. Only John should be able to see the entire table, and the rest of the Devgroup should be able to see the table minus the Rate column. In this case, you create column security by protecting the Rate column with a user-level ACL permission statement for John. The Devgroup members can have full table permissions at the group level, but cannot see the protected column because John's user-level column security ACL overrides any group-level ACLs for the Devgroup table.For example code that implements column-level security, see Column-Level Security Example.

Persistent ACLs

A persistent ACL is an ACL that is not removed from a resource when the resource is deleted. When you are using PROC SPDO, use the /PERSIST option to identify a persistent ACL.

Giving ACL Control to Others

A resource owner can permit other users to alter his or her ACL by granting a specific user or group Control access to that ACL. In PROC SPDO, this is done with the MODIFY ACL statement.
Last updated: February 3, 2017