HP-UX Reference (11i v3 07/02) - 3 Library Functions A-M (vol 6)

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 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:
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 pass-
word 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 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, [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: February 2007 − 1 − Hewlett-Packard Company 91