hpux man page for acps

acps(3) 						     Library Functions Manual							   acps(3)

NAME
       ACPS - Access Control Policy Switch

SYNOPSIS
       [flag]... file...  [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  inter-
       faces:

       An Application Programming Interface that access-control-aware applications
		      can call to request an authorization decision.  See acps_api(3) for more information.

       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 infor-
		      mation.

       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

       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  appropri-
       ate, 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 under-
       standing 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
       HP-UX username associated with the subject.

       RFC822 identifier of the subject (for example,

       HP-UX UID associated with the subject encoded as a

       X.500 identifier of the subject (that is,

   Credential Types
       Kerberos ticket encoded in ASN.1 DER.

       Cleartext password.

       Cleartext pin represented as a string.

       SAML credential assertion.

       Base64 ASCII encoded certificate.

   Subject Attributes
       Comma-delineated list of (active) roles associated with the subject.

       The GECOS information associated with the subject, as defined in the
	      passwd file or other Name Services Switch repository.

       Comma-delineated list of groups associated with the subject.

       The shell associated with the subject, as defined in the passwd file
	      or other NSS repository.

   Operation Types
       Literal encoded operation string.

       Hierarchically encoded operation string using "." as the separator.

   Object Types
       CIM version 2.8 object representation encoded in XML.

       File object encoded as a path.

       Object encoded as a generic string with no additional interpretation.

       Object encoded in uri syntax.

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

RETURN VALUES
       The requested access was granted.  This return code is only returned as a result of requests.

       The ACPS is configured incorrectly.
	      This might be the result of a syntactic error in the file.

       The requested access was not granted.
	      This return code is only returned as a result of requests.

       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 call , the application should not allow access to the specified resource.

       The requested operation failed as a result of an error allocating or
	      de-allocating memory.

       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 again, which might result in	an  allow.
	      If the application cannot supply the necessary credential, it should treat this result as equivalent to an

       The repository has no access control information on the user.
	      This return code is only returned as a result of requests and is never returned to an application.

       The requested operation was successful.
	      This is never returned as the result of a request.

SEE ALSO
       acps_api(3), acps_spi(3), acps.conf(4), rbac(5).

																	   acps(3)