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 PowerServer 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.
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.
PowerServer Web applications and PowerServer 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.
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.
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 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: PowerServer Toolkit deploys the INI files as XML to PowerServer. 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 PowerServer.
-
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", "") ...
