Defining Transaction Authentication

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.

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.