Security operations

This section describes how to configure access management when not using Central Governance.

You can implement the security system gradually. This topic describes how to customize the security configuration. You can activate the security mechanisms by object or by type of object.

Individual privileges can be declared and activated. You can activate them immediately when you need them. Alternatively, you can declare a set of privileges in one session and then activate them individually at a later date. In the second case, the security system is operational, but all actions are authorized.

The security system can operate in the proprietary mode or in a mode that is external to Transfer CFT.

Control processes

PARAMETER, PARTNER, OPERATOR, COMMAND classes

Control process

Control Process Actions

Step

Process action

1

The user sends a service request.

The corresponding Transfer CFT component processes the request and returns the:

  • action
  • name of the object concerned
  • class to which the object belongs
  • value of the object

If the user or group identifier corresponds to the identifier of the command creator, the action is authorized and control is returned to the Transfer CFT component concerned.

2

A call is sent to the operating system to obtain the:

  • user identifier
  • group to which the user belongs, if applicable

3

The object dictionary is accessed to determine the search mode to be applied by the security system (proprietary or OS).

4

Control is switched to the internal or external security mechanism.

5

The response from the mechanism can be:

  • positive: the user is authenticated and control is returned to the Transfer CFT component associated with the service request
  • negative: an error message is generated and the request is rejected

 

TRANSFER, APPL, FILE classes: general transfer case

Transfers, whether files or messages, are processed in the same way. Only the identifier is different: request IDF for a file transfer and request IDM for a message transfer.

The file is processed by analyzing the user identifier of the local application (USERID in the CFTAPPL command). This user must have the appropriate privileges to use the file to be sent or received (CREATE, READ, WRITE, DELETE, RENAME). This check is performed by the operating system.

The end of transfer and error procedures are submitted to the operating system with the user identifier of the local application (USERID in the CFTAPPL command).

The following table shows the various control stages implicit in requester/sender, requester/receiver and server/sender transfers.

TRANSFER, APPL, FILE classes - general transfer control stages

Stage Component Processing

Utility

(CFTUTIL, API) 

No control is performed
The request is stored in the communication medium with the name of the USERID for whom the application is running

All users can write to the communication medium 

CFTMAIN 

Command parsing:

  • Syntax check
  • Value substitution

Privilege check on the command creator for a CREATE action on the APPL object 

Determination of the transfer owner by scanning for a CFTAPPL corresponding to the IDF
If no CFTAPPL matches, the transfer is rejected 

Privilege check on the transfer owner:

  • File identifier (IDF)
  • Partner
  • File name (FNAME)
  • Direction

If the operation is authorized, go to Stage 3
Otherwise, a message is recorded in the CFT log 

CFTTFIL 

File processing in the external security mode only
Transfer CFT checks that the user who owns the transfer has:

  • READ rights for the corresponding FNAME
  • DELETE rights if the FACTION=DELETE option is set for the IDF

TRANSFER, APPL classes: server/receiver transfer

Transfers, whether files or messages, are processed in the same way. Only the identifier is different: request IDF for a file transfer and request IDM for a message transfer.

The file is processed by analyzing the user identifier of the local application (USERID in the CFTAPPL command). This user must have the appropriate privileges to use the file to be sent or received (CREATE, READ, WRITE, DELETE, RENAME). This check is performed by the operating system.

The end of transfer and error procedures are submitted to the operating system with the user identifier of the local application (USERID in the CFTAPPL command).

The following table shows the various control performed.

TRANSFER, APPL classes - sender/receiver transfer controls

Component Processing

CFTMAIN 

Determination of the transfer owner by scanning for a CFTAPPL corresponding to the IDF
If no CFTAPPL matches, the transfer is rejected 

 

Privilege check on the transfer owner:

  • File identifier (IDF)
  • Partner
  • Direction

 

If the operation is authorized, go to Stage 3
Otherwise, a message is recorded in the Transfer CFT log 

TRANSFER class: transfer with voluntary switching

The following table lists the controls performed on the various sites.

TRANSFER class: Controls on transfers with voluntary switching

Site Processing

Sender 

Standard requester/sender transfer controls 

 

Privilege check on the command creator for a CREATE action on the COMMUT object (first intermediary partner and final receiver) 

Intermediary 

Check for the existence of a local application with the COMMUT identifier
Check that the user declared for the local application is authorized to process the file 

 

For VAN switching (processing on the switching site):

  • Check that the user declared for the local application is authorized to submit the procedures
  • Control of the SEND commands

Receiver 

Standard server/receiver transfer controls 

TRANSFER class: reply type message transfer

The creator of a REPLY-type transfer is considered to be the same as the creator of the associated transfer.

START, HALT, END, KEEP, SUBMIT and DELETE commands

These commands are controlled by the APPL and ALL_CAT objects.

Controls on the ALL_CAT Object

The monitor invokes the security system:

  • to check the START, HALT, END, KEEP and SUBMIT commands with the ALL_CAT object and the CONTROL action
  • to check the DELETE command with the ALL_CAT object and the DELETE action

If the user has the appropriate privileges, there is no control on the APPL object and the command is executed.

Controls on the APPL object

If the control via the ALL_CAT object fails, Transfer CFT invokes the security system:

  • To check the user’s authorization to access the identifier IDF of the APPL object during the CONTROL action for the START, HALT, KEEP, END, and SUBMIT commands
  • To check the user’s authorization to access the identifier IDF of the APPL object during the DELETE action for the DELETE command

If the authorization is not granted, the command is rejected and the corresponding message is recorded in the Transfer CFT log.

Related Links