acps(3)

NAME

ACPS — Access Control Policy Switch

SYNOPSIS

#include <acps.h> 
#include <acps_api.h> 
#include <acps_spi.h> 

cc [flag]... file... -lacps [library]...

DESCRIPTION

The Access Control Policy Switch (ACPS) provides a layer of separation between applications that must make authorization decisions and the underlying modules that provide a decision response by interpreting some form of pre-configured policy. The switch provides three interfaces:

ACPS API: An Application Programming Interface that access-control-aware applications can call to request an authorization decision. See acps_api(3) for more information.
ACPS SPI: A Service Provider Interface (SPI) that allows custom modules to provide access-control decisions. A module can write to the SPI to plug-in to the applications that call the API. See acps_spi(3) for more information.
acps.conf: A configuration interface (file configuration) that administrators use at deployment time to select the module (or set of modules) referenced to make authorization decisions. See acps.conf(4) for more information.

Each of these interfaces is described in greater detail in their corresponding manpages.

Access Request Fundamentals

The ACPS framework recognizes three fundamental components of an access control request:

. B Subject: The entity attempting to access the resource. In the context of an operating system, the subject is commonly a user or a process associated with a user.
Operation: An action performed on a resource. An operation can correspond directly to an application or command. In the case of HP-UX RBAC, the operation is a dot-separated, hierarchical string such as hpux.user.add.
Object: The target of the operation. This is often the same as the end resource.

In addition to these core components, there are sometimes additional attributes of the subject, operation, object, or environment that affect the access control decision. The ACPS framework is designed to allow the application to specify additional attributes as appropriate, and convey this information to the modules configured to reply to the request.

The final piece of information passed through the ACPS is a form of proof that the subject is actually who he or she claims to be. This proof, called a credential, can be in several different forms, for example a password or a Kerberos ticket. Depending on the decision provider and its established trust relationship with the application, a credential might be optional.

PARAMETER TYPES

The ACPS framework is designed to allow the application to pass various attributes to the decision provider. To facilitate a common understanding of the possible types of attributes and components, the ACPS framework requires most parameters to carry an associated type that might be implicitly or explicitly specified.

These types are common to both the application interface (API) and the decision provider interface (SPI) and are defined as follows:

Subject Types

ACPS_ID_NAME: HP-UX username associated with the subject.
ACPS_ID_RFC822: RFC822 identifier of the subject (for example, user@hp.com).
ACPS_ID_UID: HP-UX UID associated with the subject encoded as a char *.
ACPS_ID_X500: X.500 identifier of the subject (that is, LDAP DN).

Credential Types

ACPS_CRED_KERBTICKET: Kerberos ticket encoded in ASN.1 DER.
ACPS_CRED_PASSWORD: Cleartext password.
ACPS_CRED_PIN: Cleartext pin represented as a string.
ACPS_CRED_SAML: SAML credential assertion.
ACPS_CRED_X509CERT: Base64 ASCII encoded certificate.

Subject Attributes

ACPS_SUBATTR_ASSIGNEDROLES: Comma-delineated list of (active) roles associated with the subject.
ACPS_SUBATTR_GECOS: The GECOS information associated with the subject, as defined in the passwd file or other Name Services Switch 'passwd' repository.
ACPS_SUBATTR_GROUPS: Comma-delineated list of groups associated with the subject.
ACPS_SUBATTR_SHELL: The shell associated with the subject, as defined in the passwd file or other NSS 'passwd' repository.

Operation Types

ACPS_OP_BASIC: Literal encoded operation string.
ACPS_OP_DOTHEIRARCHICAL: Hierarchically encoded operation string using "." as the separator.

Object Types

ACPS_OBJ_CIM28: CIM version 2.8 object representation encoded in XML.
ACPS_OBJ_FILEPATH: File object encoded as a path.
ACPS_OBJ_GENERIC: Object encoded as a generic string with no additional interpretation.
ACPS_OBJ_URI: Object encoded in uri syntax.

Environment Attributes

CPS_ENVATTR_COMPARTMENT: Compartment tag associated with the access control request. The interpretation of "associated" is left to the application.

RETURN VALUES

ACPS_ALLOW: The requested access was granted. This return code is only returned as a result of checkauth() requests.
ACPS_CONFIG_ERROR: The ACPS is configured incorrectly. This might be the result of a syntactic error in the acps.conf file.
ACPS_DENY: The requested access was not granted. This return code is only returned as a result of checkauth() requests.
ACPS_GEN_ERROR: The requested operation failed. This is the default error code for any operation when a more specific error code does not apply. When this is returned as the result of a checkauth() call , the application should not allow access to the specified resource.
ACPS_MEMORY_ERROR: The requested operation failed as a result of an error allocating or de-allocating memory.
ACPS_NEED_AUTHENTICATION: The requested access was denied as the result of the lack of a necessary credential. After the requested credential is supplied, the application can call checkauth() again, which might result in an allow. If the application cannot supply the necessary credential, it should treat this result as equivalent to an ACPS_DENY.
ACPS_NOINFO: The repository has no access control information on the user. This return code is only returned as a result of acpm_checkauth() requests and is never returned to an application.
ACPS_SUCCESS: The requested operation was successful. This is never returned as the result of a checkauth() request.