• URL-Based Access Control - via security.ini
• File-Based Access Control - via .htaccess
• Host-Based Access Control - via security.ini and/or .htaccess

The Sambar Server implements the above access controls with two levels of authentication information. The security.ini file found in the config directory is a global access configuration file, whereas .htaccess control files are per-directory configuration files. Both access control mechanisms can be used within the server, however care must be taken not to introduce mutually-exclusive constraints.

Presently, all user-level security is independent of the native Windows NT security system. All security.ini based access controls are implemented via the sample code found in samples/source/security.c. The source code to this module was provided so that individuals that might need alternative access control mechanisms (i.e. LDAP, Windows NT domain passwords) can implement and integrate the functionality for the Sambar Server.

WARNING: Because the HTTP/1.0 authentication system transmits username and password from the browser to the server unencrypted (except when SSL is used), the use of LDAP or Windows NT domain passwords for access security introduces a significant security risk. Once a user has authenticated, the browser transmits the username and password with each request it sends thereafter, making interception a fairly easy task for anyone watching packet traffic.

URL-Based Access Control
URL-Based Access Control is the original access control model implemented by the Sambar Server. In this model, all access restrictions are implemented via the security.ini file based on the requested URL. The primary advantage of this model over File-Based (aka physical path) Access Control is that the physical file and directory locations can change without requiring the remapping of the physical structure to the existing URL space. With URL-Based access security, changes to the physical locations of documents do not change the access control layout as long as the new structure is mapped to the original URL spaces (via aliasing).

The disadvantages to this model is that all security resides in a single location and tremendous care must be taken to avoid security breaches that occur when multiple URLs map to the sample file location (i.e. use of '..', trailing periods, ~ and long file names). In addition, the configuration file is only read and parsed during server startup; the server must be restarted after subsequent modifications to the security.ini file.

File-Based Access Control
File-Based Access control was added in the 4.2 release through the support of .htaccess files. The .htaccess documentation provides details on setup and configuration. The .htaccess file formats allow for many access control mechanisms to be configured on a per-directory basis (i.e. security realms, host-based access, user and group access control lists). These per-directory configuration files are read and parsed by the server on each access, allowing run-time reconfiguration.

The primary disadvantages to .htaccess-based security is the performance degredation associated with using this model, and the lack of a browser-based mechanism for creating or maintaining .htaccess files (a GUI mechanism for configuring/modifying .htaccess files will be provided in a future release). The performance problem with .htaccess files is due to their hierarchical nature, i.e. if you have /foo/.htaccess, the configuration specified in this file must be applied to /foo/bar/xxx.htm as well as /foo/yyy.htm. This requires the server to perform a linear search for pathnames, looking for .htaccess files.

Where possible .htaccess support in the Sambar Server attempts to remain compatible with the Apache server (when NCSA and Apache implementations differ). Not all mechanisms supported by the Apache server are supported.

Host-Based Access Control
Both the security.ini file and the .htaccess file mechanisms support Host-Based access control. The security.ini file provides site-level access restrictions based on IP address, whereas, the .htaccess enables per-directory level access restrictions based on IP address.

There is, however, a significant difference in how the Host-based access control is implemented via these two security mechanisms. The security.ini rules are loaded at server startup and applied to each connection before the request is processed. As a result, if an IP Address is on the DENY list, the connection is simply closed without any additional processing or logging. This layer of security is optimal for blocking some forms of security attacks.

The .htaccess restrictions are applied after the HTTP request is read and a significant amount of processing has occurred (enough to build up the server-side request handles, and map the URL request to a directory). If an IP address is on the "deny from" list in the .htaccess file, a 401 (Not Authorized) error message is returned.