Defining Transaction Authentication

This procedure provides guidance and information on implementing transaction authentication.


The following items should be addressed prior to performing this procedure:

  • Determine if the transaction should require authentication at all times or conditionally. If conditionally, determine the specific conditions and the values on the client involved in the determination to support the creation of the rule definition that will be needed.
  • Determine the requirements for the audit trail and/or electronic signature information dictated by the back end system, including what information is needed and how it should be recorded. Note this information to support the logic needed in the back end processing for the transaction as well as in the definition of the authentication object and its properties.


The steps here include the main process to be followed as well as guidance on variations to these standards, which may be implemented depending on need. The main process presented here is the recommended best practice for implementing this functionality.


  1. Begin by defining an object, preferably named “Authentication”. Add to this object the properties needed to capture the values required for the transaction(s) for which it is to be used. If capturing the password for the user, define a string property for this purpose and set that property’s Password attribute to true. This will prevent the value of this field from being displayed on the client, and protect it from being displayed in log files and other potentially non-secure locations.

    As an alternative, it is possible to capture the authentication information in the properties of the transaction. However, the use of a separate object is the recommended method as it is easier to define and better supports conditional authentication.

  2. Next define a screen to set to display the Authentication object definition. Add to it the platform(s) needed for the environment. Finally, define the detail screens and fields to display the properties from the Authentication object. Do not add button definitions to this screen set, as it will be displayed as a wizard screen set and the client will display the buttons needed automatically.
  3. The transaction for which the authentication behavior can now be modified. Navigate to the transaction and view the main Transaction Definition tab in the Properties View. In the Authentication section of this tab set the authentication attributes for Screen Set, Authenticate When, and Information In, as shown in the following example:

    If storing authentication values in the transaction properties rather than a separate object, be sure to leave the default Information In attribute setting of “Properties of this transaction.” Also, the Authenticate When attribute is where a rule can be defined and referenced. Remember the rule is evaluated in a Boolean context with a true result requiring authentication.

    At this point it is possible to publish this application and test the client-side behavior of the transaction authentication. Note that authentication-related data captured at this point will not be processed to the back end system.

  4. OPTIONAL: If condition transaction authentication is defined, a property should be added tot he transaction itself to be used as a flag indicating whether or not the authentication was performed for the transaction instance. The recommended practice is to define a Boolean property and to set the property to be initialized by a rule. In most cases the rule used to determine if the authentication should occur can also be used to initialize the Boolean property.
  5. The final part of the transaction authentication is to define the logic to process the authentication data to the back end system. This is specific to the back end system’s requirements for such information. When defining the step, authentication-related data is accessed using the SDML data tags <<transaction.authenticationObjectName.propertyName>>. For Java system connections, the values can be accessed in the TransactionSession class using the get methods and passing in the property names in the form transaction.authenticationObjectName.propertyName. In either syntax, the name of the object and the name of the property are used. The other standard transaction values, including properties and the transaction’s time stamp are also accessible. Once the step is defined it can be run as a server update step within the transaction. If performing conditional authentication on the client, be sure the logic to process the authentication data checks the flag property value in the transaction to determine if the transaction was authenticated or not.


With the completion of this procedure, the transaction has been defined to require the user to authenticate themselves on the client before the transaction is applied and saved. Depending the specifics of the configuration, the authentication may be conditional.

Next Steps

Once this procedure is complete, the behavior should be thoroughly tested in an appropriate environment. Testing should include verification of the client-side behavior, especially any and all scenarios related to conditional authentication. Back end processing should also be verified as accurate and again scenarios should factor in any conditional authentication.