Design Functional Security

Security › How to Prevent Unauthorized Access in Applications › Design Functional Security

Design Functional Security

Functional security restricts access to application functions within a procedure. The application must provide all logic to implement functional security.

The approach to implementing functional security in a client/server environment is similar to the common action block option for implementing application coded transaction security. For more information, see Coding Security Logic.

The functional security check should occur early in the procedure by using a common or external action block, preferably one of the first statements.

The called or used action block first needs to import the user ID, transaction code, and function requested. Then the logic should read a file or a database table to determine the transaction authority for the imported information:

If a user does not have the appropriate functional authority, the execution of the transaction will be terminated and a message will be returned to the client procedure.
If the user does have the appropriate functional authority, the action diagram returns an exit state or return code that allows further processing.

This approach is similar to how the CA Gen Security Template implements security.

Functional security can be enhanced in the client/server environment by enabling or disabling controls in the CA Gen GUI designer. Disabled controls on a GUI window can prevent a user from selecting an item to which they do not have access. By extending the functional security to the client window, the security integrates effectively with the GUI interface, and the application's usability increases.

For example, a customer information list procedure contains two functions, detail the customer information and view the customer credit history. Selecting a push button starts both functions.

Access to view customer credit history is limited to loan officers only. When a loan officer opens this window, both push buttons can be selected. When any other user opens the window the detail customer information push button is enabled, but the view credit history is disabled. The window manager prevents the non-loan officer user from selecting the push button.

The disabling can also proactively prevent unauthorized use. If the push button were not disabled, the non-loan officer user could select the view credit history button but be notified of a security violation after the selection.

The type of functional security described in this example can be implemented in all client/server applications. The security information used for disabling is retrieved from the server. The GUI controls are disabled based upon that information.

Follow these steps:

On all GUI windows that have controls (such as push buttons and menu items) and require security, create an import and export work attribute view for each control to be secured.
The views must contain a 1-byte attribute for each control that will be disabled. The attribute will hold either a Y or a space:
- The Y indicates that the user has access to the control and can perform the function represented by the control.
- A space indicates the user does not have access to the control and cannot perform the function.
The flag attribute will be populated by the server procedure via an export view. Using the customer information list example, the secured control is the view customer credit history push button.

The import and export views to secure the push button are:
- IMPORT SECURE
- CREDIT_HISTORY_FLAG
  and
- EXPORT SECURE
  CREDIT_HISTORY_FLAG
Place the flags on the window so that the Disabled By feature of the window painter can be used to disable the controls if necessary.
Hide the flags from the user by one of these methods:
- Extending the window or dialog box beyond its normal size
- Adding a read-only attribute in an extreme corner of the window
- Resizing the attribute to the smallest size
- Returning the window to its normal size
In the customer information list example, the EXPORT SECURE CREDIT_HISTORY_FLAG will be placed on the window (see Step 1).
After the flag is placed on the window, use the Disabled By feature of the GUI painter to detail each control that requires disabling. Set each control to be disabled when the appropriate attribute flag does not have data.
It is important that a space in the flag attribute indicate no access because when a window is initiated all functions will be disabled. If Y indicated no access then when the window is initiated, then all functions would be enabled. Continuing with the customer information list procedure example, the view customer credit history push button would be disabled in the following way:
```
THE PUSH BUTTON 'View Credit' IS DISABLED WHEN
```
```
ENTRY FIELD 'Credit_History_Flag' DOES NOT HAVE DATA
```
Enable and disable the controls by defining each client procedure as Execute First. This property should be set for all procedure interactions and the clear screen input property of the procedure.

The client procedure action diagram should have logic for the initial execution of the client that is sent to the server procedure to determine what functions the user can perform. This initial check can occur either by itself or bundled with another service request.

The following sample code shows example action diagram logic for retrieving security information for the function Security Check.
```
 ---
```
```
|    CASE OF COMMAND
```
```
|     ---
```
```
|    |    CASE firstime
```
```
|    |
```
```
|    |--- NOTE*****************************
```
```
|    |    Initial execution               
```
```
|    |    Get function Security Information
```
```
|    |    *********************************
```
```
|    |    COMMAND IS security
```
```
|    |    USE PSTEP server (or EXIT STATE IS link_to_server)
```
```
|    |    CASE grafdel
```
```
|     ---
```
```
 ---
```
At the server, a service must be provided that accepts as input the transaction code of the client procedure and the logged on user ID. It should return to the client procedure the access flags that hold the users authority. The following sample code is the action diagram logic that is contained within the server for the functional security check.
The following sample code shows an example action block for checking security authorizations for the function Security Check.
```
 ---
```
```
|    CASE OF COMMAND
```
```
|     ---
```
```
|    |    CASE security
```
```
|    |
```
```
|    |    NOTE**********************************
```
```
|    |    Check Security Authorizations for user
```
```
|    |
```
```
|    |    USE check_security
```
```
|    |    WHICH IMPORTS: Work View import client_procedure_step
```
```
|    |    WHICH EXPORTS: Work View export secure
```
```
|    |
```
```
|    |    CASE initial
```
```
|     ---
```
```
 ---
```
Functional security should be re-validated at the server with each request for a secured function to assure integrity.