Access to In-Memory Data :: SAS® Visual Analytics 7.4: Administration Guide

SAS LASR Authorization Service

Overview

The SAS LASR Authorization Service collaborates with the metadata authorization layer to manage user access to in-memory data.

The following figure depicts the authorization process:

Authorization Process

1	In a SAS Visual Analytics client, a user performs an action that uses a SAS LASR Analytic Server. In this example, the request is to read data. The client sends the request to the authorization service. Note: Other examples of actions include requesting analysis of data, loading tables, appending rows, and stopping the server.
2	The authorization service requests the following information from the metadata server: authorization decisions that indicate whether the requesting user has the effective metadata-layer permissions that are required to perform the requested action. See Permissions by Task. the security key for the target SAS LASR Analytic Server
3	The authorization service receives the authorization decisions and security key from the metadata server. If the requesting user has a conditional grant of the Read permission, the authorization service also receives a clause (or set of clauses) that specifies which rows the user can access.
4	If the requesting user has effective grants of all permissions that are required for the requested action, the authorization service provides a signed grant to the client. Note: The authorization service uses the security key to create the signed grant. The signed grant includes the table name, the type of action (for example, Table Info, Summary Statistics, or Regression), and any applicable row-level security conditions.
5	The client submits the signed grant to the SAS LASR Analytic Server.
6	The SAS LASR Analytic Server uses its knowledge of the security key to validate the signed grant that the client supplies. If the signed grant is valid, the server provides access to the requested in-memory table (conforming to any row-level security conditions in the signed grant).

Security Keys

A LASR security key is a unique, shared secret between a SAS LASR Analytic Server and the metadata server. LASR security keys are created and stored as follows:

When a SAS LASR Analytic Server is started, a key is generated. In the SAS LASR Analytic Server, the key is stored in memory. The key is also stored in metadata in the password field of a login object that is associated with the server’s connection object.
If a SAS LASR Analytic Server is stopped, the associated key remains in the metadata. If the server connection is restarted, a new key is generated. The new key replaces the existing key in the metadata.

Note: A LASR security key is a SAS internal construct. Do not confuse LASR security keys with encryption key passphrases. See On-Disk Encryption of SASHDAT Files.

Caching

To avoid making repeated queries to the metadata server for a security key, the authorization service caches the key. When the cache interval has expired, the authorization service removes the key from the middle-tier cache. When the next request is made for in-memory data, the authorization service again obtains the key from the metadata server and repopulates the cache.

To enhance performance, the authorization service caches information about users and permissions. When a SAS Visual Analytics user accesses a data source in the SAS LASR Analytic Server, a user object is created and cached. A permission object is also created and cached for the data source. These are middle-tier, session-based caches.

The duration of each cache is set by the las.caching.* properties. See Configuration Properties.

Signature Files

Signature files are created when a SAS LASR Analytic Server is started (server signature files) and when a table is loaded (table signature files). The location for each server’s signature files is specified in the server’s metadata definition.

Manage access to the signature files directory as follows:

Anyone who performs task that generate signature files must have Write access to the directory.
Any service accounts that perform tasks that generate signature files must have Write access to the directory. For example, if you use automated data loading, the account under which the scheduled task runs must have this access.
Nobody else needs access to signature files. (Access from SAS Visual Analytics clients to the SAS LASR Analytic Server and its in-memory data is controlled by metadata permissions.)
Host-layer access controls on signature files determine access for any requests that are not mediated by the SAS LASR Authorization Service. For this reason, it is important to restrict access to signature files.

Host-protect the signature files directory as follows:

In SAS Management Console, right-click on a SAS LASR Analytic Server, and select Properties.
On the Options tab, click the Advanced Options button.
In the Advanced Options window, select the Additional Options tab. Note the path that is specified in the Signature files location on server field.
Host-protect the directory, using the following guidelines:

Windows Specifics: Limit Read and Write access as described above.

UNIX Specifics: For a distributed server, the UMASK value of the TKGrid determines the permissions on signature files. Set the TKGrid UMASK to 077. For a non-distributed server, set the personal UMASK to 077. These settings prevent any user other than the file owner (creator) from gaining access to signature files.

Server Tags

Server tags are identifiers that help the SAS LASR Authorization Service map each in-memory table to a corresponding metadata object. See In-Memory LASR Names.

Each LASR library’s server tag must be defined as follows:

If the LASR library’s data is loaded from co-located HDFS or NFS-mounted MapR, the server tag must be the source path in dot-delimited format. Here are some examples:

Source Path	Corresponding Server Tag
`/hps`	`hps`
`/hps/special`	`hps.special`
`/sales`	`sales`

If the LASR library’s data is loaded using SAS Embedded Process, the server tag must be valid as a SAS libref. For example, the server tag cannot be MyServerTag (more than eight characters) or user.sasdemo (more than one level).
If the LASR library’s data is loaded from a legacy co-located provider, the server tag must be the source library’s libref (for example, TDLIB or GPLIB).
Otherwise, the server tag can be any unique string. If you do not supply a server tag in a LASR library’s metadata definition, the tag WORK is used.

CAUTION:

Within a server instance (a host-port combination), each server tag must be unique.