acps_api man page on HP-UX

Man page or keyword search:  
man Server   10987 pages
apropos Keyword Search (all sections)
Output format
HP-UX logo
[printable version]

acps_api(3)							   acps_api(3)

NAME
       acps_api:   acps_addenvattr(),	acps_addobjattr(),   acps_addopattr(),
       acps_addsubattr(),  acps_addsubcred(),  acps_checkauth(),   acps_end(),
       acps_setobj(),	acps_setop(),  acps_setsubid(),	 acps_start()  -  ACPS
       Application Programming Interface

SYNOPSIS

       [flag]... file...  [library]...

DESCRIPTION
       The ACPS Application Programming Interface (API) defines a set of func‐
       tions  that  an application writer can use to perform an access control
       check.  This check is typically used to determine whether a  particular
       user has access to a resource.

       The  ACPS  API  provides	 both a simplified interface for requesting an
       access check and a more flexible interface that allows  an  application
       to  specify additional access control attributes.  For both interfaces,
       the basic access control request takes the form:

	      Is subject X allowed to perform operation Y on object Z?

       This request is formed  using  different	 functions  depending  on  the
       application requirements.

   Simplified Interface
       In the simplified interface, this basic question is represented as fol‐
       lows:

       For a typical request, this query returns either or based on the policy
       represented  in	the  configured	 modules.   This will suffice for many
       applications, but the query makes several simplifying assumptions about
       the types of representations used for the user identity, operation, and
       object.	Specifically for this request, the identity is assumed to be a
       username	 the operation a typical HP-UX operation string and the object
       a generic string For more information on these types, see acps(3).

   Detailed Interfaces
       For the more complex requests, the query takes the forms described in

       There are a few major components to this set of interfaces.

       The and functions are used for memory allocation	 and  deallocation  to
       maintain state between the calls.  The that is passed to each call is a
       pointer to an opaque data structure.  The memory for this structure  is
       allocated as part of the call to and freed in

       The  subsequent calls to to and essentially encode information into the
       handle in preparation for a call to  The	 five  pieces  of  information
       encoded are as follows:
	      Subject  identification  (for  example a username, uid, or X.500
	      DN) and associated attributes (for example, role, groups).

	      Subject credentials (for example,	 a  password  and/or  Kerberos
	      token).

	      Operation and associated attributes.

	      Object and associated attributes.

	      Environment  attributes  (for example, compartment ID, processor
	      usage,
		     and so forth).

       For this information the interfaces encode a single value into the han‐
       dle.   Subsequent calls to the same interface will overwrite the previ‐
       ously written value.  This is in contrast to the interfaces that append
       the value to a chain of values.	The interfaces are used for the values
       that uniquely identify an access control request.  The  interfaces  are
       used  for  credentials  and  attributes,	 of  which  any	 number may be
       present.

       The call to triggers an authorization request to be  marshaled  to  the
       back-end	 modules based on the ACPS configuration.  The backend modules
       are able to retrieve the information stored in the handle as  indicated
       in acps_spi(3).

       One  additional	interface  not shown in the above code fragment is the
       following optional interface that an application may choose to call  if
       it receives from the call:

       This  function  returns	a string that indicates the type of credential
       that the policy requires.  It is expected that an application  may  use
       this  interface	to  request additional credentials from the user (when
       needed).	 The application can then add the credentials  to  the	handle
       using and then re-call

       The ACPS API only accept strings encoded in the C locale.

RETURN VALUE
       The  values  returned  by  the  ACPS  API (as well as the ACPS SPI) are
       defined in acps(3).

EXAMPLES
       The following example illustrates the use of of the  simplified	inter‐
       face in a sample application:

       #include <stdio.h>
       #include <libacps_api.h>

       int
       main(int argc, char **argv)
       {
	  int ret;

	  if(argc != 4) {
	       fprintf(stderr, "Usage:	chkauth username operation object\n");
	       exit(1);
	  }

	  ret = acps_simplecheckauth(argv[1], argv[2], argv[3]);

	  if(ret == ACPS_ALLOW) {
	       printf("Access Allowed\n");
	  }
	  else if(ret == ACPS_DENY) {
	       printf("Access Denied\n");
	  }
	  else {
	       printf("Error returned: %d\n", ret);
	  }

	  return ret;
       }

SEE ALSO
       acps(3), acps_spi(3).

								   acps_api(3)
[top]

List of man pages available for HP-UX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net