JGuiGen and Security
[Previous] [Main] [Next]

JGuiGen and Security

Accessing a database professionaly requires attention to a number of factors including data validation, user friendliness, corporate standards, and security.

JGuiGen is designed with security in mind. While it is not perfect, there has been considerable attention paid to access the corporate data securely.

·Authentication - This can be as simple as a list of names in the JGuiGenIni.xml file or as complex as accessing a user name and password in an LDAP data store. If you use the LDAP option, it can be a simple file based system or a stnadard LDAP such as Novell's NDS or MS's Active Directory. When you use LDAP, the system encrypts you personal password, the username and password used to access your database and the user name and password used to access LDAP. If a hash of the user supplied password decryptes the username and password to access LDAP and matches the hash stored there, the user in connected to the database (by unencrypting the database username and password.) This system is described in the README.HTML file.  
·Authroization - Each screen JGuiGen generates can be given a screen number. Individual users can be given different rights to different screens either by storing the data in a table or by storing in your LDAP.  
·Encrypted fields - JGuiGen has the capability to store selected fields in the database in an encrypted format. The password that decryptes these fields is stored in an encrypted format that is unique for each user.  
·Encrypted access across a network - JGuiGen comes with code that can be used to set up an SSL link to a remote database. Traffic to and from this database on the network is encrypted.  
·Logging - Access is documented and the user changing a row is logged into each row when the row is changed. Optionally text copies of all updates can be stored in JGuiGen's log file.  
·Until further notice there is one hole in the JGuiGen security that we are working on. When a user saves a query using FIND button they are offered the option to save the query and edit it. This opens the door to SQL insertion. We have decided to give the developer the option to turn off this feature in their generated applications. If you trust your users (for example the application is for yourself or for developers who already have complete access to your database) you can turn the option on. If not you can turn the option off. I am looking for a way to keep this functionality and close the hole.  
·As of May 10, 2006 I am converting JGuiGen updates and queries to use Prepared Statements. This won't mean a huge speed advantage since must of the updates are different. It will however provide much more protection from SQL injection attacks on your database from users of JGuiGen generated applications.