This document is written to give system administrators and installation technicians a quick introduction to the Foundation1 Security Checkpoint concept in IFS Applications.
Administrators are recommended to read about how to Manage Security Checkpoint Log. System configuration technicians are recommended to read about how to Setup Security Checkpoints. Developers are recommended to read Developing Security Checkpoints.
Note: This is only available on sites with an IFS Development License.
The purpose with security checkpoints is to provide extra security in a specific function, method or business flow. With an activated security checkpoint on a function you will have to authenticate yourself again in order to fulfill the function. Additionally, whenever a security checkpoint is successfully passed a security checkpoint log is written, creating an audit trail of what is done..
Security Checkpoint simplified flow chart
Security Checkpoint is designed for prevent this attack scenario:
If Security Checkpoint is enabled for specific business flows, Mallory cannot perform these actions without authenticating (i.e. entering correct password) as the logged on user. Therefore these fraudulent attempts will be terminated.
The Security Checkpoint user interfaces are designed to allow the user to approve an transaction, or optionally cancel it. To approve it, the user need to enter username and password. Important features to this interface includes;
Username - The username is with default settings filled in with the user's username. It is also possible to configure Security Checkpoint so the user always need to retype the username. No other username than the current user's username will be accepted.
Password - Password authentication is the default authentication scheme for Security Checkpoint. Because the end user knows the username of the logged on user, the end user can be assumed to be the same as the logged on user, with a reasonable amount of assurance.
Comment - This field allows users to comment transactions they know might look strange to auditors; which ideally will reduce auditors need to investigate legitimate transactions and be quicker to single out the actually illegitimate transactions in the Security Checkpoint audit logs.
OK button - The OK button is pressed when the Security Checkpoint information is properly filled in.
Cancel button - The idea with the cancel button is that this dialog will help users think twice when doing important transactions, and that they might often choose to cancel, recheck entries (and maybe do some changes) and then submit changes again. Also, by offering a cancel button, the user is never faced with the "I'm stuck, I need to approve this whatever it is to get unstuck, now I approve and I don't care what" feeling.
Security Checkpoint is designed to allow authentication with Hardware Security Tokens. However no hardware security token is supported by default; token specific customizations are required to enable this functionality.
Challenge - This field displays challenges from an authentication server, which is then typically entered by the user into a small hardware security token, in order to generate a response code.
Response - This field allow the user to enter the response code provided by the Hardware Security token. Response may either be the response to a challenge, or it could be the code displayed on a simple OTP-pad.
Security Checkpoint user interface in Web Client
Security Checkpoint user interface in IFS Enterprise Explorer
The audit log shows which Checkpoint ID was completed, a server generated Message which identifies which changes has occurred in the transaction, the Comment entered by the user, the Transaction Date and the User Name of the user who completed the Security Checkpoint. The interface is further described in Manage Security Checkpoint Log.
The Security Checkpoint Log displaying entries
A Security Checkpoint Gate is only open during a transaction, as soon as one transaction is ended the Security Checkpoint Gate is closed again. If more than one Security Checkpoint Gates are active during one transaction, then only the first one requires authentication by user. That is after first active Security Checkpoint is passed all other gates are open, until the transaction ends.
In order to have Security Checkpoint concept working you must configure the PL/SQL Access Provider. The user will supply his/hers password, which will be authenticated by the Application Server the PL/SQL Access Provider is connected to. Application Server must not be configured for "Externally Identified" nor "No authentication".
If the Application Server requires Windows / Active Directory username, and users normally logon using IFS Windows Client and using Oracle passwords (which are not synchronized with Active Directory), users may be confused by using two different passwords. Such a configuration is not recommended.
Security Checkpoint has four system parameters that configures the behavior of the Security Checkpoint concept.
| Parameter | Description |
|---|---|
| Security Checkpoint framework available | This parameter can be ON or OFF. ON means that the Security Checkpoint Concept is activated and Security Checkpoint Gates is checked during transactions. OFF means that the Security Checkpoint concept is not activated. No Security Checkpoint Gates are considered. |
| Type of hardware support for Security Checkpoint | This parameter shows whether Challenge Response is going to be used
or not. When challenge response is used the Security Checkpoint shows a
challenge that should be responded. SIMPLE no challenge response is used. CHALLENGE_RESPONSE challenge response is used. Only SIMPLE is supported by default. In order to
use CHALLENGE_RESPONSE extra implementation is needed. |
| Security Checkpoint method | This parameter determines what authentication type should be used in
Security Checkpoints. PASSWORD only password is required. PASSWORD_AND_HARDWARE both password and hardware response is required. HARDWARE only hardware response is required. Only PASSWORD is supported by default. In order to
use HARDWARE or HARDWARE_AND_PASSWORD extra implementation
is needed. |
| Cleanup age limit in days for Security Checkpoint Logg | This parameter determines how many days a Security Checkpoint Log should
reside in the table before it is cleaned up by Light Cleanup process. Example: 7 means the logs stays in one week before cleaned up. Special value: 0 means that the log entries remains until someone cleans the log manually. |
A Security Checkpoint Gate consists of two parts, configuration and implementation code.
Configuration
The configuration consists of a unique id, a description and a Security Log message with possibility to add substitution parameters. In the configuration you can activate or inactivate each individual Security Checkpoint Gate.
Implementation code
In order to work a Security Checkpoint Gate must have some implementation code executed in some business flow. If wanted you can use the same Security Checkpoint Gate in many business flows, but this gives you less possibility to auditing or tracing of what have happened in the different business flows.
The Security Checkpoint log is where you can trace where any user has passed a Security checkpoint. The log gives you information about who, when and a message about what have passed this Security Checkpoint Gate in a particular business flow.
When ever a successful Security Checkpoint occurs a event, called SECURITY_CHECKPOINT_SUCCESS, is executed. This event can be configured to execute specific code, like sending a mail, whenever a successful Security Checkpoint occurs.