acps.3 (2010 09)

a
acps(3) 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 interpret-
ing 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:
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 applica-
tion 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 pro-
vider. 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 expli-
citly 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, [e-mail]).
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).
HP-UX 11i Version 3: September 2010 − 1 − Hewlett-Packard Company 1