Skip to content

Security Checkpoints

The purpose of security checkpoints is to provide extra security in a specific function, method or business flow. An active security checkpoint on a function means that the user will have to authenticate again, in order to fulfill the function.

Please read more about the concept Security Checkpoints.

There are two development steps to create a security checkpoint. The first step is to create the registration part that defines the security checkpoint and the second step is to add the logic that invokes the security checkpoint from the correct place in the business logic. The implementation is done in PL/SQL in the Server business logic.

How does Security Checkpoint work

Below is a description of what ihappens when a Security Checkpoint occurs in the code.

  • The client sends the business transaction to the server.
  • The server code hits a Security Checkpoint then the server raises a special exception.
  • Implicitly upon the exception the server rollbacks the last changes that are made in the database.
  • The client framework handles the exception and brings up the Security Checkpoint authorization page.
  • If the Security Checkpoint is passed the client resends the business transaction to the server.

Security Checkpoint Attributes

A security checkpoint has 3 attributes; a Security Checkpoint ID, a description and a message.

Security Checkpoint ID

Security Checkpoint ID is also referred to as Gate ID. This is a string value that identifies the security checkpoint. The ID should be unique in the system. The ID should be prefixed with the IFS component where it is defined, for example SINWOF or DOCMAN. If the checkpoint is used in several components it is also possible to use a more general prefix that describes the area.

Example:  SINWOF_INVOICE_AUTHORIZING

Description

The description is displayed to the system administrators that activates the checkpoint and monitors the checkpoint logs. It should describe the process that is protected from a business perspective and not describing the actual implementation details.

Message

The purpose of the message is to provide useful information to system administrators who are monitoring the Security Checkpoint log. It is possible to include parameters from the PL/SQL application logic into the message. The "&" character in the message is used to indicate parameters that should be replaced by the actual value in runtime.

Example:  Person &PERSON_ID approved Document Revision &DOC_CLASS - &DOC_NO - &DOC_SHEET - &DOC_REV.

The message explains what has occurred and what business object was affected (in this example, a document revision identified by &DOC_CLASS-&DOC_NO-&DOC_SHEET-&DOC_REV was approved). This information will be written to the Security Checkpoint Log each time a user runs a business flow and enters an active checkpoint and the user is authenticated successfully. Note: Avoid including text such as ”checkpoint”, ”gate”, ”authentication”, ”password” etc in the message, as it is redundant text which is common for every single security checkpoint. Also avoid including the fnduser or the transaction date; this information is always added to each log entry.

Register a Security Checkpoint

A security checkpoint is defined in a ".ins" file in the database source folder. The registration is done by calling the method Sec_Checkpoint_Gate_API.Register with a unique ID and a IFS Message that contains the definition of the security checkpoint.

PROCEDURE Register (  
 gate_id_  IN VARCHAR2,  
 info_msg_ IN VARCHAR2)

The info_msg_ is an IFS Message that includes the description of the checkpoint, the message and a flag if it should be activated by default. Parameters used in the message must also be added. This is added as an IFS Message named PARAMETERS within the main message. The example below shows registration of a message and shows the names of the attributes used in the IFS Message.

Inserting Security Checkpoint into a business flow

A BSA should determine whether a security checkpoint is required from a  business perspective. From a technical point of view it is important that the security checkpoint is as early in the business process as possible, since the code is run before the security checkpoint and also after the security checkpoint is passed.

The security checkpoint is invoked by calling the method Security_SYS.Security_Checkpoint.

PROCEDURE Security_Checkpoint (  
gate_id_  IN  VARCHAR2,  
msg_ IN  VARCHAR2)

The parameter msg_is an IFS Message named SECURITY_CHECKPOINT. This message should contain the same parameters as registered and values set for each one of them. See example: