Appeon security features are set in AEM, the Web application that manages the Appeon system and deployed Web or mobile applications. Appeon security is at the application level and is "either or": the user either has or does not have access to the application. By default, Appeon security is turned off for each deployed application.
When the security for a Web or mobile application is turned on, the Appeon Login dialog box pops up at the beginning of the application startup and prompts the user to enter the user name and password. The user name and password are verified by PowerServer against the authentication schema that can be set in an LDAP server or in PowerServer system database. If the user name or password is not correct, the user is not allowed to access the PowerServer application.
For more information on using the Appeon security features for the PowerServer Web application or the PowerServer mobile application, refer to the Server Security section.
If your PowerBuilder application has not coded user name/password verification at application startup that restricts access to the application, you can utilize Appeon's built-in user group management. When the application runs, the user is prompted to enter the Appeon user name and password in the Appeon Login dialog box.
The Appeon user name can be passed to the application so that it can be utilized to implement script coded security features for the application. You can use the of_getappeonusername function in the Appeon Workarounds PBL to get the Appeon user name. For detailed information, refer to the section called “AppeonExtFuncs Object” in Workarounds & APIs Guide.
In Client/Server architecture, the database can easily keep track of every logged-in user if you enable the AUDITING option in the database.
PowerServer Web applications and PowerServer mobile applications run in a three-tier architecture. Each time the Client wants to connect with the database, the call reaches PowerServer first. PowerServer will validate the user ID and password of the call. If the validation passes, PowerServer connects with the Database Server using a unified user ID and password. The user ID and password that the database keeps track of is not the user ID and password that makes the call at the Client.
To work around the database auditing functionality, you can also re-configure the auditing information that is saved on the database by adding a new field to it: user ID.
With the Client/Server application, make sure that a combination of user ID and password cannot hold multiple connections with the database at one time.
Add in the necessary code in the Client Server application so that every time the user wants to connect with the database, the call sent to the Database Server includes user ID information. For example, when sending the user ID as a column in the DataWindow or to the Stored Procedure, the user ID information in the call from the client-side will be saved in the user ID field on the Database Server.
