CHAPTER 10: Security Features




10.1 Introduction

The idea behind Toolkit security is that it is possible to allow certain users into certain areas of your internet application, and deny access to others. This capability takes a little setting up, because the developer must integrate HTTP directory access control with the Connectivity (ODBC) Server password file and database privileges themselves. Various levels and combinations are possible, from a completely open application to one which requires users log on to the browser and be registered with both the HTTP and Connectivity Servers. For many internet applications, the users will not even be known and a generic default user should be set up. Various sections of an application can have varying levels of security. It is possible to have open sections and secure sections of an application.


10.2 HTTP Access Control

The front line of defense is the directory access control available on most HTTP servers. Setting this up is different for every Server, but the basic concept is that any directory, or directory tree and their passwords. Then when any client request is for information stored in these directories the client is prompted for log-on information. The log-on information is then valid for the session life of the client browser.

This is true whether the directory contains HTML files, or is a CGI directory containing executable programs.

Since the Toolkit accesses documents via the CGI directory it is the CGI directory that requires security, not the HTML pages. Thus on HTTP Servers that require a number of different levels of access it is often desirable to set up multiple CGI directories containing copies of the HTML Toolkit programs that have different HTTP access control - and can be inididually configured for database access as well.

If you have HTTP access control on your documentation then this makes the log-on username of the client available to the Empress HTML Toolkit. This is available as a CGI variable called REMOTE_USER.



10.3 HTML Application Scope

By default the HTML Toolkit looks for HTML pages directly under the DocumentRoot of the HTTP Server. Thus if the URL was:

   http://My-bin/ehsql.cgi/a/b/c.html

The Toolkit would look for a document located at:

   DocumentRoot/a/b/c.html

The EH_DOC_ROOT resource variable modifies this behaviour. With this variable set, the Toolkit would look for a document located at:

   DocumentRoot/EH_DOC_ROOT/a/b/c.html

This has two purposes:



10.4 Empress Connectivity Server Access Control

After the HTTP server access control. The next level of access is to the Empress Connectivity Server. In order to access this server an application must have a valid username and password registered in the Connectivity Server password file.

There are three possible security scenarios at this point:

If you wish to associate a password with the REMOTE_USER you can set a resource variable in the ehtml.ini file that has a name the same as the value of the REMOTE_USER, and a value that is the password.

Generally, when using HTTP access control it is best to IGNORE_REMOTE_USER and use a general DEFAULT_USER for the given CGI. Because most applications, once accessed would have the same level of access for everyone; and when you required a different level of access you would use a separate CGI. For example, one CGI for read/write access, and a separate CGI for read only access.



10.5 Empress Database Access Control

The last security level for the system is the database itself. Each account name in the Connectivity server must be granted privileges on the database that is to be accessed. Each account can be granted various levels of access on each table in the database: no access, read only access, read/write access, right through to DBA access. Details of how to set up these privileges are given in the Empress SQL Reference manual.

Each CGI username should be given the minimum access that is needed to run the HTML Toolkit access applications. For example:



10.6 Example

You have two applications: one of which is a read only database, open to all users, the other of which is a read/write application used to administer the tables in the database.

These applications are located under:

   DocumentRoot/open/user/accounts

   DocumentRoot/admin/user/accounts

The toolkit CGI's for these applications are set as ScriptAliases open and empadmin, and the empadmin ScriptAlias is set up to use HTTP server access control. The ehtml.ini files for these two CGI directories would then contain:

ehtml.ini for open

   DEFAULT_USER=bert
   DEFAULT_PASSWORD=berts_password
   EH_DOC_ROOT=/open/user

ehtml.ini for empadmin

   DEFAULT_USER=ernie
   DEFAULT_PASSWORD=ernies_password
   EH_DOC_ROOT=/admin/user
   IGNORE_REMOTE_USER=true	

This would cause the open CGI to access the Connectivity Server as bert, and the empadmin CGI to access it as ernie.

These would therefore have to be valid accounts in the Connectivity Server password file.

Since open is a read only CGI the bert account would be granted SELECT privileges on the tables in the database. But. since empadmin is an administration application, the ernie account would be granted ALL privileges on the tables.