Application Security

For typical PowerBuilder applications, security is implemented at two levels: script coded security and database security. After conversion, the Appeon system provides an additional built-in layer of application security on top of PowerBuilder application security. Appeon security is "either-or": the user either has or does not have access to the application.

You can implement security for the deployed Web or mobile applications in many ways. PowerBuilder script-coded security can convert direct to the Web or the mobile, and it provides security for the applications. There are also ways to implement database security in the Web or mobile applications. Finally, you can use the Appeon user/group management system to restrict access to the Appeon applications.

In addition, a way to incorporate the Appeon user/group management for use with the coded security in PowerBuilder applications is discussed in Incorporate Appeon security in PowerBuilder code. You can also implement your own security using other technologies.

Database security

Depending which user logs into an application, a PowerBuilder application can dynamically change the Transaction properties (user ID and password etc.) and connect to the database with different identities that determine the user privileges to access, read or modify the database tables.

Appeon Web applications and Appeon mobile applications rely on the data sources to interact with the Database Servers. In the Web or mobile application, transaction object to data source mapping can be dynamically set up or changed by setting or changing the DBMS and DBParm properties of the Transaction object in the application source code, or it can be statically set up in AEM database configuration. There is a limitation with data source configuration: the user ID and password of a connection must be pre-configured in AEM or application server console. Due to this limitation, you may want to consider the workarounds introduced in this section to improve the migration of database security in the original application.

Workaround one: Predefined data sources

You can pre-define in AEM or application server console a certain number of data sources that correspond to different security access levels in the database with different user IDs and passwords. When the user logs in, the application decides which transaction object to data source mapping to use for establishing the database connection.

You should set up an equal number of data sources in AEM or application server console that connect to the database with different privileges, and map the data sources dynamically using the Transaction DBParm property to the PowerBuilder Transaction objects. Transaction object to data source mapping can be dynamically set up or changed by setting or changing the DBMS and DBParm properties of the Transaction object in the application source code. See Dynamic transaction object to data source mapping for the details.

Workaround two: The distributed application technique

The distributed application technique is supported by Appeon to work around the database security features in a PowerBuilder application. The methodology is to encapsulate the PowerBuilder source code that implements the database securities into NVOs and run them on EAServer. The NVOs may perform actions like creating database connections (manipulation of Transaction object properties), manipulating DataStore objects or executing SQL statements, and transferring the returned information to the Client.

For example, you can encapsulate the user authentication logic into an NVO, and then deploy the NVO to EAServer. In the application source code, you only need to pass the username and the password from the login window to the NVO.

Step 1: Create an NVO and declare a method in the NVO for user authentication. The method compares the user information entered in the application login window with that retrieved from the system table.

The method declared in the NVO:

public function boolean of_checkuser (string 
as_userid, string as_password); 
String ls_DBPass
SELECT fpassword
	INTO :ls_DBPass
	FROM t_user
	WHERE t_user.fuserno = :as_userid;
if sqlca.SQLCode <> 0 Then
	return false
End If
if ls_DBPass <> as_password Then
	return false
End If
	return true
End function

Step 2: Deploy the NVO to EAServer and create a proxy object for the NVO in the Client application.

Step 3: Modify the user authentication logic in the Client application to get the user information from the login window and pass it to the NVO.

The modified script in the Client application:

String ls_User,ls_Pass,ls_DBPass,ls_Err
Long ll_ID
String ls_Mess = 'Please enter a valid user
ID/password.'
If Trim(sle_name.Text) = '' Then
	sle_name.SetFocus()
	MessageBox('Login Not Valid', ls_Mess, exclamation!)
	Return
End if
ls_User = Trim(sle_name.Text)
ls_Pass = Trim(sle_Pass.Text)
If i_logsec.of_checkuser(ls_User,ls_Pass) then
	MessageBox("Infomation","Login successful!")
Else
	MessageBox("Infomation","Login failure!")
End if

Using INI files for connection security

You can set connection properties for a PowerBuilder application either by assigning values to the properties in the application script or using PowerScript Profile functions to read from an initialization (INI) file. It is recommended by Appeon that you set connection properties by reading from INI files only if your environment meets the following requirements:

  • The browser for accessing the application must be cookie-enabled.

    Reason: Appeon Developer deploys the INI files as XML to Appeon Server. When a Client accesses the deployed application that uses the INI file profiles, a copy of the original XML file is specially created and carries all the profile information of the Client. The cookie on the Client browser enables the Client to read the correct copy of its XML file located on Appeon Server.

  • Make sure the Windows user account profile on the Client is only used by one user for accessing the application.

    Reason: As the Cookie will reside in the Windows user profile cookie directory (for example, C:\Documents and Settings\Administrator\Cookies) any user with full access rights who also uses the Client computer will be able to gain access to another user's application identity.

If the same Windows user account profile will be used by multiple users on the Client, consider using another security method, Database security, as introduced in the Database Security section.

The initialization file should at least consist of the Database section:

[Database]
variables and their values
...

The following script example assigns connection properties to SQLCA. The database connection information is stored on the Web Server after application deployment; on some network configurations this can leave the database server unsecured:

SQLCA.DBMS = "MSS Microsoft SQL Server"
SQLCA.Database = "appeon_test"
SQLCA.ServerName = "192.0.0.246"
SQLCA.LogId = "sa"
SQLCA.AutoCommit = False
...

To set the Transaction object to connect to a database, the following script example reads values from App.INI, an initialization file. This method is much more secure in comparison to the preceding script.

sqlca.DBMS = ProfileString(App.INI, "database",&
"dbms", "")
sqlca.database = ProfileString(App.INI,&
"database", "database", "")
sqlca.userid = ProfileString(App.INI, "database",&
"userid", "")
sqlca.dbpass = ProfileString(App.INI, "database",&
"dbpass", "")
...