Glossary: Glossary :: SAS(R) 9.2 Intelligence Platform: Security Administration Guide

Glossary

access control template: a reusable named authorization pattern that you can apply to multiple resources. An access control template consists of a list of users and groups and indicates, for each user or group, whether permissions are granted or denied. Short form: ACT.
authentication: the process of verifying the identity of a person or process within the guidelines of a specific authorization policy.
authentication domain: a SAS internal category that pairs logins with the servers for which they are valid. For example, an Oracle server and the SAS copies of Oracle credentials might all be classified as belonging to an OracleAuth authentication domain.
authentication provider: a software component that is used for identifying and authenticating users. For example, an LDAP server or the host operating system can provide authentication.
authorization: the process of determining which users have which permissions for which resources. The outcome of the authorization process is an authorization decision that either permits or denies a specific action on a specific resource, based on the requesting user's identity and group memberships.
capability: an application feature that is under role-based management. Typically, a capability corresponds to a menu item or button. For example, a Report Creation capability might correspond to a New Report menu item in a reporting application. Capabilities are assigned to roles.
client-side pooling: a configuration in which the client application maintains a collection of reusable workspace server processes. See also puddle.
connection profile: a client-side definition of where a metadata server is located. The definition includes a computer name and a port number. In addition, the connection profile can also contain user connection information.
credential management: the reuse of cached credentials or the retrieval of stored credentials from the metadata.
credentials: the user ID and password for an account that exists in some authentication provider.
direct LDAP authentication: a configuration in which the metadata server sends credentials to an LDAP provider (such as Active Directory) for validation, bypassing the host authentication process.
encryption: the act or process of converting data to a form that only the intended recipient can read or use.
external identity: a synchronization key for a user, group, or role. For example, employee IDs are often used as external identities for users. This is an optional attribute that is needed only for identities that you batch update using the user import macros.
host authentication: a process in which a SAS server sends credentials to its host operating system for verification.
Integrated Windows authentication: a Microsoft technology that facilitates use of authentication protocols such as Kerberos. In the SAS implementation, all participating components must be in the same Windows domain or in domains that trust each other.
internal account: a SAS account that you can create as part of a user definition. Internal accounts are intended for metadata administrators and some service identities; these accounts are not intended for regular users.
internal authentication: a process in which the metadata server verifies a SAS internal account. Internal authentication is intended for only metadata administrators and some service identities.
IWA: See Integrated Windows authentication.
login: a SAS copy of information about an external account. Each login includes a user ID and belongs to one SAS user or group. Most logins do not include a password.
PAM: See pluggable authentication modules.
permission condition: a control that defines access to data at a low level, specifying who can access particular rows within a table or particular members within an OLAP cube. Such controls are typically used to subset data by a user characteristic such as employee ID or organizational unit. For example, an OLAP cube that contains employee information might have member-level controls that enable each manager to see the salary history of only that manager's employees. Similarly, a table that contains patient medical information might have row-level controls that enable each doctor to see only those rows that contain data about that doctor's patients.
pluggable authentication modules: an industry-standard technology that extends UNIX host authentication to recognize additional authentication providers.
puddle: a group of servers that are started and run using the same login credentials. Each puddle can also allow a group of clients to access the servers.
repository access control template: the access control template (ACT) that controls access to a particular repository and to resources for which access controls are not specified. You can designate one repository ACT for each metadata repository. The repository ACT is also called the default ACT.
restricted identity: a user or group that is subject to capability requirements and permission denials in the metadata environment. Anyone who isn't in the META: Unrestricted Users Role and isn't listed in the adminUsers.txt file with a preceding asterisk is a restricted identity.
role: a set of capabilities. In some applications, certain actions are available only to users or groups that have a particular role.
SAS authentication: a form of authentication in which the target SAS server is responsible for requesting or performing the authentication check. SAS servers usually meet this responsibility by asking another component (such as the server's host operating system, an LDAP provider, or the SAS Metadata Server) to perform the check. In a few cases (such as SAS internal authentication to the metadata server), the SAS server performs the check for itself. A configuration in which a SAS server trusts that another component has pre-authenticated users (for example, Web authentication) is not part of SAS authentication.
SAS token authentication: a process in which the metadata server generates and verifies SAS identity tokens to provide single sign-on to other SAS servers. Each token is a single-use, proprietary software representation of an identity.
server-side pooling: a configuration in which a SAS object spawner maintains a collection of reusable workspace server processes that are available for clients. The usage of servers in this pool is governed by the authorization rules that are set on the servers in the SAS metadata.
service identity: an identity or account that exists only for the purpose of supporting certain system activities and does not correspond to a real person. For example, the SAS Trusted User is a service identity.
single sign-on: an authentication model that enables users to access a variety of computing resources without being repeatedly prompted for their user IDs and passwords. For example, single sign-on can enable a user to access SAS servers that run on different platforms without interactively providing the user's ID and password for each platform. Single sign-on can also enable someone who is using one application to launch other applications based on the authentication that was performed when the user initially logged on.
SSO: See single sign-on.
trusted user: a privileged service account that can act on behalf of other users on a connection to the metadata server.
unrestricted identity: a user or group that has all capabilities and permissions in the metadata environment due to membership in the META: Unrestricted Users Role (or listing in the adminUsers.txt file with a preceding asterisk).
user context: a per-session, in-memory list of credentials that are available to a particular user.
Web authentication: a configuration in which users of Web applications and Web services are verified at the Web perimeter and the metadata server trusts that verification.
well-formed user definition: a user definition that includes a login with an appropriate user ID. For a Windows account, the user ID in the login must be qualified (for example, WIN\marcel or marcel@company.com). The login does not have to include a password. For metadata administrators and some service identities, it is appropriate to use an internal account instead of a login.

Top of Page