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 Security Checkpoints in IFS Development Guide.
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 the current user will have to re-authenticate 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 was 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 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.
The Security Checkpoint service can be enabled or disabled using IFS Solution Manager.
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.