The remote authorization API uses the following files:
where ACDir is the directory you installed CA ControlMinder in, by default /opt/CA/AccessControl
Example
The following program demonstrates how a client application can perform a remote authorization check:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <memory.h>
#include <unistd.h>
#include “api_auth.h”
#include “langapi.h”
int ShowUsage(void)
{
fprintf( stderr, “Usage:\n”
“ rmt_auth User‑Name Class‑Name Resource‑Name“
“Access“
return 1;
}
int main(int argc, char *argv[])
{
char *output;
int rv;
API_AUTH_RES result;
char input[200];
char *Passwd = NULL;
if ( argc != 6 )
return ShowUsage();
Passwd = getpass(“Please enter your password:”);
if ( Passwd == NULL )
{
printf(“Illegal password!!\n”);
return 1;
}
/*
* Initialization. get the host name and password from the
* command line parameters
*/
rv = lca_rmtauth_Init(“rmt_auth”, &output, argv[5], Passwd);
if ( rv )
{
printf( “Return value: 0x%08x\n”
“%s\n”, rv, (output) ? output : “Initialization failed” );
return 1;
}
Passwd = NULL;
/*
* Send the request to the server and get the result
*/
rv = lca_rmtauth_CheckAccess(argv[1], argv[2], argv[3], argv[4], &result);
if ( rv )
{
printf(“Return value: 0x%08x\n”
“Remote Access Check failed\n”, rv);
return 1;
}
/*
* Print the results.
* Further analysis as for the reasons for granting/denying
* access can be made at this stage
*/
printf(“%s's access %s to %s %s at %s is %s!!\n”,
argv[1], argv[4], argv[2], argv[3], argv[5],
((char) result.result == 'P') ? “Permitted” : “Denied”);
lca_Terminate();
}
After compiling and linking this example, you can check whether a user is authorized to access a specific resource. For example, to see whether user Joe has read access to file /etc/passwd, type the following command:
rmt_auth Joe FILE /etc/passwd Read authorization‑server‑name
You are prompted for your password, after which you receive the reply.
The Authorization and Authentication API consists of the following functions:
Converts an error string into the integer representing the error code.
Checks whether a user is authorized to access a resource using the specified access type.
Creates an ACEE handle for a user.
Deletes a user's ACEE handle.
The SEOSROUTE_ParseApiError function parses the error string returned by the verification and authentication functions and returns the integer value associated with it.
Notes:
int SEOSROUTE_ParseApiError(const char *szErrMsg);
The error string returned by CA ControlMinder in the *szMsg parameter
The SEOSROUTE_RequestAuth function asks seosd whether the specified user is allowed to access the specified resource using the specified access type.
The SEOSROUTE_RequestAuth function sends the request to seosd, which first checks whether the parameters are valid. If they are, seosd performs its standard resource authorization check: Is the specified user authorized to access the specified resource in the specified way?
The first five parameters must be supplied by the application; the last two parameters are returned by CA ControlMinder and can be used by the application to make decisions and provide the user with status information.
The function returns an integer that takes on one of the following values:
The user is allowed to access the resource as requested.
An invalid access authority was specified.
The request was denied.
The seosd daemon is not responding.
The user ID of the calling process is not 0 (root), and the user executing the calling process does not have the SERVER attribute.
The daemon or service returned an error described in szMsg.
Notes:
A server application normally calls SEOSROUTE_VerifyCreate before calling SEOSROUTE_RequestAuth, to get an ACEE handle for the user whose authorization is being checked.
int SEOSROUTE_RequestAuth(const char *szClass,
const char *szEntity,
int hACEE,
SEOS_ACCESS *pAccess,
int LogOpt,
API_AUTH_RES *pRes,
char *szMsg);
The name of the class to which the resource belongs.
The name of the record, or object, representing the resource being accessed.
Note: The case of the szEntity parameter is important when the szClass supports case-sensitive objects.
The ACEE handle of the accessor. To specify the ACEE of the user associated with current process, specify SEOSAPI_AUTH_CURRACEE. Specifying an ACEE handle other than SEOSAPI_AUTH_CURRACEE requires the user associated with the calling process to have the SERVER attribute or the calling process to be running under the effective user ID of 0 (root).
A pointer to a structure containing the requested access. The structure contains the single data member access of type SEOS_ACCS. Valid values for this member are:
A flag that determines whether an audit log entry must be made. Valid values are:
For regular users, which are not root, if the authorization request succeeds, do not create an audit record. If the authorization request fails, create an audit record if the current rules in the database require auditing.
For server applications and for root users, do not create an audit record, regardless of whether the authorization request succeeds or fails (value = 0).
If the current rules in the database require it, create an audit record (value = 1).
For regular users, this is an invalid option and is mapped to SEOSAPI_AUTH_LOG.
For server applications, always create an audit record regardless of the database rules (value = 2).
For regular users, this is an invalid option and is mapped to SEOSAPI_AUTH_LOG.
For server applications, create an audit record only if the authorization request fails and the database rules require it (value = 3).
For regular users (including root), if the authorization request succeeds, do not create an audit record. If the authorization request fails, create an audit record if the current rules in the database require auditing.
For server applications, do not create an audit record, regardless of whether the authorization request succeeds or fails (value = 4).
Do not create an audit record (value = 5).
A pointer to the API_AUTH_RES structure containing the authorization result.
A pointer to a buffer SEOSAPI_AUTH_MSGLEN into which CA ControlMinder returns a status message.
The SEOSROUTE_RequestAuthAzn function sends seosd an authorization request. CA ControlMinder first checks whether the parameters are valid. If they are, CA ControlMinder performs its standard resource authorization check realized in function SEOSROUTE_RequestAuth.
Important! This function is obsolete and is available for backward compatibility purposes only.
If the function succeeds, the return value is zero. Otherwise, the return value is an error code.
int SEOSROUTE_RequestAzn (
LPCSTR szClass,
LPCSTR szEntity,
LPCSTR szAccess,
HANDLE *phUserAttributes,
int hACEE,
int LogOpt,
API_AZN_RES *pres,
API_RESP_TAB **response,
LPCSTR szMsg
);
The ACEE handle of the accessor.
A flag that determines whether an audit log entry must be made.
A pointer to a hash table created by the function SEOSROUTE_Create RequestAzn. This pointer is related only to the SEOSD process.
A pointer to the API_AZN_RES structure containing the authorization result.
A pointer to the buffer containing the response list.
A pointer to a null terminated string that specifies the access name corresponding to the object described by szEntity.
A pointer to a null terminated string containing the name of the resource class.
A pointer to a null terminated string containing the name of the object representing the resource being accessed.
Note: The case of the szEntity parameter is important when the szClass supports case-sensitive objects.
A pointer to a buffer SEOSAPI_AUTH_MSGLEN bytes long into which CA ControlMinder returns a status message.
The SEOSROUTE_CreateRequestAzn function sends seosd an array of the user attributes relating to same user and receives pointers specifying a hash table created on the user attributes base.
Note: It is important to call the SEOSROUTE_CloseRequestAzn function after processing a user.
If the function succeeds, the return value is zero. Otherwise, the return value is an error code.
INT SEOSROUTE_CreateRequestAzn(
LPCSTR szUserDir,
DWORD cEntries,
LPAPI_AZN_USERATTR pUserAttr,
PHANDLE phUserAttributes,
LPSTR szMsg
);
Pointer to a null terminated string specifying the user directory.
Value specifying the number of the API_AZN_USERATTR structures in array pointed to by pUserAttr. Cannot be zero (0).
Pointer to an array containing user attributes.
If the function succeeds, the parameter specifies a pointer to a hash table calculated using user attributes.
If the function fails, the value is INVALID_HANDLE_VALUE.
A pointer to a buffer SEOSAPI_AUTH_MSGLEN bytes long into which CA ControlMinder returns a status message.
The SEOSROUTE_CloseRequestAzn function removes the hash table pointer by hUserAttributes. After calling this function, SEOSD cannot process authorization requests for the specified user unless SEOSROUTE_CreateRequestAzn( ) is processed again.
If the function succeeds, the return value is zero. Otherwise, the return value is an error code.
INT SEOSROUTE_CloseRequestAzn(
HANDLE hUserAttributes,
LPSTR szMsg
);
A pointer to a hash table calculated using user attributes.
A pointer to a buffer SEOSAPI_AUTH_MSGLEN bytes long into which CA ControlMinder returns a status message.
The API_AZN_USERATTR structure specifies attribute information.
typedef struct tagAPI_AZN_USERATTR {
char szAttName[ONAME_SIZE];
char szAttVal[ONAME_SIZE];
}API_AZN_USERATTR, *PAPI_AZN_USERATTR, FAR *LPAPI_AZN_USERATTR;
Null terminated string containing the attribute name.
Null terminated string containing the attribute value.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|