DEFINE_SECURITY_ACCESS_LIST defines a list of users who can access
a particular local LU or invokable TP, so that access to that LU
or TP is restricted to the named users. It can also be used to add
user names to an existing security access list. The user names in
the list are defined using the DEFINE_USERID_PASSWORD verb.
To restrict access for a particular local LU or invokable
TP, you need to do the following:
Ensure that
each authorized user of the LU or TP is defined using the DEFINE_USERID_PASSWORD
verb.
Use the DEFINE_SECURITY_ACCESS_LIST
verb to define a security access list containing all of these user
IDs.
Specify the name of this
security access list on the DEFINE_LOCAL_LU or DEFINE_TP verb that
defines the LU or TP.
When an incoming Allocate request arrives for a local LU or
an invokable TP that has a security access list defined, the invoking
application must indicate that conversation security is to be used,
and specify a user ID. In addition to the standard conversation
security checking (against user IDs specified using the DEFINE_USERID_PASSWORD
verb), SNAplus2 checks the user ID in the incoming allocate request
against the security access list defined for the LU or TP, and rejects
the conversation if the user ID does not match. If both the LU and
the TP have security access lists defined, the user ID must be in
both lists.
If a local LU or an invokable TP does not have a security
access list defined, but is still configured to require conversation
security, the standard conversation security checking still applies.
VCB
Structure |
 |
The DEFINE_SECURITY_ACCESS_LIST verb contains a variable number
of security_user_data structures; these define the user names to be
added to the security access list.
The user name structures are included at the end of the def_data structure; the nmber of these structures is specified
by the num_users parameter.
typedef struct define_security_access_list
{
AP_UINT16 opcode; /* verb operation cod */
unsigned char reserv2; /* reserved */
unsigned char format; /* reserved */
AP_UINT16 primary_rc; /* primary return code */
AP_UINT32 secondary_rc; /* secondary return code */
unsigned char list_name[14]; /* name of this list */
unsigned char reserv3[2]; /* reserved */
SECURITY_LIST_DEF def_data; /* security access list */
} DEFINE_SECURITY_ACCESS_LIST;
typedef struct security_list_def
{
unsigned char description[32]; /* description */
unsigned char reserv3[16]; /* reserved */
AP_UINT32 num_users; /* number of users being added */
unsigned char reserv2[16]; /* reserved */
} SECURITY_LIST_DEF;
typedef struct security_user_data
{
AP_UINT16 sub_overlay_size; /* reserved */
unsigned char user_name[10]; /* user name */
} SECURITY_USER_DATA;
|
Supplied
Parameters |
|
The application supplies the following parameters:
- opcode
AP_DEVINE_SECURITY_ACCESS_LIST
- list_name
Name of the security access list. This is an ASCII string,
padded on the right with spaces.
If this name matches an existing security access list, the
users defined by this verb are added to the list; otherwise, a new
list is created.
- def_data.description
A null-terminated text string (0 - 31 characters followed
by a null character) describing the security access list. This string
is for information only. It is stored in the node’s configuration
file and returned on the QUERY_SECURITY_ACCESS_LIST verb, but SNAplus2
does not make any other use of it.
- def_data.num_users
Number of user names being defined by this verb.
Each user must be specified by a security_user_data structure following the def_data structure.
For each user name in the list, up to the number specified
in num_users, a security_user_data structure is required with the following information:
- user_name
Name of the user. This is a user ID defined using
the DEFINE_USERID_PASSWORD verb.
Returned
Parameters: Parameter Check |
|
If the verb does not execute because of a parameter error,
SNAplus2 returns the following parameters:
- primary_rc
AP_PARAMETER_CHECK
- secondary_rc
Possible values are:
- AP_INVALID_LIST_NAME
The list_name parameter contained a character that was not valid.
- AP_INVALID_USER_NAME
One or more of the specified user names was not
valid.
Appendix A “Common
Return Codes” lists further
secondary return codes associated with AP_PARAMETER_CHECK, which
are common to all NOF verbs.
Returned
Parameters: Other Conditions |
|
Appendix A “Common
Return Codes” lists further
combinations of primary and secondary return codes that are common
to all NOF verbs.
Printable version
