Appeon security features are set in Appeon Enterprise Manager (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 Appeon Server against the authentication schema that can be set in an LDAP server or in Appeon system database. If the user name or password is not correct, the user is not allowed to access the Appeon application.
For more information on using Appeon security features for Appeon Web or Appeon mobile applications, 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.
Appeon Web applications and Appeon mobile applications run in a three-tier architecture. Each time the Client wants to connect with the database, the call reaches Appeon Server first. Appeon Server will validate the user ID and password of the call. If the validation passes, Appeon Server 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.
If you are using a SAP ASE database, you can use the SSA data source property. This property changes the ID at the database to whatever user ID/Password is used by end users for accessing the server. If you are using an SAP database, you can set this property in your data source props file. This cannot be used if you are using a different database type.
The following information is taken from the EAServer Administrator Guide Appendix B - Data Source Properties; please refer to the EAServer documentation for more detailed instructions.
The data source property, com.sybase.jaguar.conncache.ssa, enables set-proxy support for connections to databases that support this feature. By default, the property is set to false, which disables set-proxy support.
This feature can be used with any database that recognizes this command:
set session authorization "login-name"
When proxy support is enabled, connections retrieved from the cache are set to act as a proxy for the user name associated with the EAServer client. To set the proxy to another user name, use the Java JCMCache.getProxyConnection() method or the C JagCmGetProxyConnection() routine in your component.
The user name specified in the cache properties (com.sybase.jaguar.conncache.username) must have set-proxy privileges in the database and/or server used by the cache.
In EAServer Manager, set this property using the All Properties tab in the Data Source Properties dialog box.
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.
