Copyright © 1998-2001 Stipe Tolj. All rights reserved. Apache Distributed Authoring Environments for collaborative web application development Stipe Tolj

Copyright © 1998-2001 Stipe Tolj. All rights reserved.

Apache Distributed Authoring Environments

for collaborative web application development

Stipe Tolj <[email protected]>

Technology Center & Research Lab

Wapme Systems AG, Düsseldorf, Germany

http://www.wapme-systems.de

Stipe Tolj, April 04, 2001W18 - Apache Distributed Authoring EnvironmentsSlide 2 of 36

Introduction

First of all we concentrate in this document on the issues of how to create, organize and maintain a working environment which is considered to be called a web side, a web application or a system of web site applications that form a more complex application.

We all deal with the development of web applications that are considered the logical level of a client server environment on top of the HTTP protocol. This is usually referred to as a web site.

Like in industrial production environments the web application development processes have been getting more and more complex as the functionality and the amount of collaborative parties participating in this effort. The need of structured concepts and ease of coordination towards these aims are getting also more and more important for those organizations that deal with this problem.

We´ll assume that you have at least basic knowledge of the following web application techniques that are used within this concept

� Apache HTTP Server� WebDAV� SSL� MySQL

We´ll describe a more detailed cookbook on which modules you´ll need to re-build the whole concept.

Introduction

Scenario

What is the Problem?

Modules

VirtualHosts

Conditional directives

Step1:mod_dav

Step 2:Splitting VirtualHosts

Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl

Step 6:mod_auth_mysql

Apache Configuration Overview

System Architecture Overview

Final Conclusions


Scenario

In order to describe the problems that usually come up in a complex web application setup and for those organizations dealing with a lot of web sites we make the following assumptions to our usage scenario

� You are running a number of individual machines as web site hosts.� Those are not located within your own local area network, but are hosted at your

ISP due to bandwidth and network reliability reasons.� You are using Apache‘s name based VirtualHost concept.� Your web site development users consist of collaboratively working parties like web

designers, web application engineers and others.

Basically, these assumptions fit into a variety of real world development and production environments all over the world. Therefore the complexity of organizing such a development environment can be divided into the following main scopes

� number of independent machines you are using (the host level)� number of independent virtual hosts each machine is serving (the vhost level)� number of independent users that are developing or deploying applications (hence

basically writing to the web site) (the user level)

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions



Usually concepts start to be a problem or a performance bottleneck when they don´t support the aims they were originally introduced anymore. That´s the same for web application development. The non-sophisticated concepts that are still used to ensure that development and hence evolution of web applications is done are no longer considered to be enough in terms of ease of use and simplicity of maintenance.

These are the main problems you are facing

� Apache is an HTTP server and does usually not support uploading files.� FTP is used in common to transfer any kind of files to the remote file system that

is serving the web application.� You have to manage user accounts on the system level to allow FTP access to the

machine. If you want to ensure that certain users have only write permissions to specific vhost data you will have to maintain groups on the system level.

� If users are working on several vhosts that are spread across several physical machines and maybe even several operating systems then the maintenance of the proper access restrictions is getting really a mess.

� FTP has usually no own IP based access restriction mechanisms and hence exploits any machine to a potential attacker.

� FTP does not use any secured (SSL) connections for transferring the files. But in terms of a new economy company, the application logic is one of the most valuable assets and hence you are not willing to exploit this.

� FTP is really old and hence there are a couple of lacks towards the abstraction of a non-transparent model for collaborative and distributed web authoring environments.

All of these problems will be addressed step by step.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Using modules for our solution

Basically we won´t provide any new module for Apache to solve our needs. We are using existing modules developed by contributors to the open source world.

Those modules are used by many people for purposes they have been originally written for, but usually don´t have anything in common.

The configuration setup we´re using for our solution glues those modules to a real world distributed authoring environment for collaborative web development.

The additional modules we are using are

� mod_dav� mod_ssl� mod_auth_mysql

Note: A couple of modules which are already part of Apache are used too (even if you may not notice this directly)

� mod_so� mod_auth_foo� mod_access� mod_log_config

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Name based VirtualHost configuration

Following our scenario assumptions we are having several VirtualHost containers set up on one single Apache installation.

This section within the configuration file (i.e. httpd.conf) would be feasible for including all other VirtualHosts

[...]

NameVirtualHost 1.2.3.4:80

include conf/vhosts.conf

[...]

Where vhosts.conf may contain global directives (which are introduced later) and the single include statements for the VirtualHost container file which is named the same way as the ServerName directive

[...]

include conf/vhosts/www.foo.com

[...]

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Name based VirtualHost containers

A typical VirtualHost container configuration file included from the above vhosts.conf file (i.e. conf/vhosts/www.foo.com) looks something like this

<VirtualHost 1.2.3.4:80>

ServerName www.foo.com ServerAdmin [email protected] DocumentRoot /home/www/www.foo.com/htdocs <Directory /home/www/www.foo.com/htdocs> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny Allow from all </Directory> DirectoryIndex index.html index.htm ErrorLog /home/www/www.foo.com/logs/error_log CustomLog /home/www/www.foo.com/logs/access_log combined [...] additional configuration directives for modules [...]

</VirtualHost>

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Conditional module directives

In order to make your setup more sophisticated against miss-configuration you may use the <IfModule> directive to encapsulate directives that are conditional, especially when

� they are defined by external modules that are not part of the Apache distribution, like those we are using within this concept.

� you are using dynamically-loaded modules using the APXS tool and the LoadModule and AddModule directives within your main configuration file.

� you don´t want to change the whole configuration file tree if you plug-out a specific module.

Simply mark the conditional directives this way within any of the configuration files

<IfModule mod_module-name.c>

[...]

directives defined by this module

[...]

</IfModule>

Note: To simplify the further presentation of the concepts we will discard this opportunity.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


mod_dav (enabling WebDAV)

This module provides DAV capabilities [RFC 2518] for your Apache web server. It is an Open Source module provided under an Apache-style license. The module is written and maintained by Greg Stein <[email protected]>.

It´s available at http://www.webdav.org/mod_dav/

What are the features and what problems does mod_dav solve:

� Extends the Hyptertext Transfer Protocol (HTTP) and therefore Apache to write any kind of content type to the web.

� Simplicity in means of restricting write permissions for certain users or workgroups by using Apache´s own directives.

� Seamlessness, interoperable publishing of all content types to the web. Individual users and workgroups can use the Hypertext Transfer Protocol (HTTP) to directly publish their work to the web.

� Abstraction, it makes the web look like a large-grain network-accessible file system.� WebDAV has it´s own access control mechanisms which are currently not provided

within any implementation. � mod_dav has been incorporated directly into Apache´s next major release 2.0.� The implementations for WebDAV and its support across large vendor products are

increasing.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Installing mod_dav

The source code of the module itself is configured, built and installed as any usual Apache module.

For the dynamically-loaded module using the APXS tool use the following command sequence:

$ ./configure --with-apxs=/usr/local/apache/bin/apxs

$ make

$ make install

In order to inform Apache about the need to load the module you´ll have to add the following directives to your Apache configuration file (i.e. httpd.conf)

[...]

LoadModule dav_module libexec/libdav.so

AddModule mod_dav.c

[...]

Now you are ready to use your Apache as a DAV server.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Using mod_dav

To enable the usage of the DAV features you simply insert the fowling directive within a <Directory> or <Location> directive

[...]

DAV On

[...]

If the DAV directive is within a <Directory> directive, then DAV will be enabled for that particular directory and its subdirectories. For a <Location> directive, then DAV will be enabled for that portion of the URL namespace.

Additional directive for the top-level or your configuration file (i.e. outside of a <Directory> or <Location> directive) for the lock database. This directive should specify a filename that mod_dav will create. The directory should exist and should be writeable by the web server process. Use this line in example

[...]

DAVLockDB /usr/local/apache/var/DAVLock

[...]

The DAVLockDB directive can appear outside of any container or within a <VirtualHost>, it only needs to appear once, and a file extension should not be supplied.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 1: Including DAV to the VirtualHosts

Now we enable DAV for the <Directory> sections within our VirtualHosts by including the DAVLockDB directive to conf/vhosts.conf

[...]

DAVLockDB /home/www/var/DAVLock


[...]

and then using the DAV directive within conf/vhosts/www.foo.com

[...]

<Directory /home/www/www.foo.com/htdocs>

DAV On

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

[...]

Beware, this setup uses no authentication and hence anyone has full access to your files!

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Status

After performing step 1, integrating DAV to our Apache installation we make the following conclusions

� We can write to our VirtualHost <Directory> containers using DAV-enabled clients.� Therefore we excluded the need to use the File Transfer Protocol (FTP) to publish our

content types to the web.� There is no need for user accounts and group maintenance on the operating system

level to perform FTP transfers for the web development.� Currently there is no user authentication and authorization for that space. An

anonymous user would have full control of that container and hence of any files any subdirectories.

� Next step is to protect the container and implement user authentication.� User authentication should be based on groups that map to the VirtualHosts running on

a single installation.� There is still no security while transferring files to the server. You probably may be

concerned about sniffers listening on the logical network connection and try to capture content.

� This may be not important for certain content types that are public anyway, but definitely if it contains logic of the web application. Imagine PHP files including SQL server credentials or Java™ servlets containing credentials to application servers etc.

� What about transferring files that are placed above the current <Directory> scope? Think of a servlet or PHP include file sub-directory.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Splitting into public and DAV VirtualHost

There are basically a couple of reasons why it is more then desirable to split the logical VirtualHost serving the web application to at least two independent VirtualHosts

� one for serving the public web application listening to port 80 and including all the required modules like mod_php, mod_jserv, etc.

� one for serving the distributed authoring needs of that web application listening to a different port or to a different ServerName scope.

The main reasons for that are

� Apache (1.3.x) has a particular design restriction in that only one content handler is allowed to process a request. There are multiple stages involving authorization, access checking, MIME type handling, etc, but there is only one content handler. This problem comes up whenever a server-side scripting solution (like PHP) is used and this is very likely to be the fact if we hold to our assumptions we made.

� Authentification is not desirable for the public access to the web application in common. You may scope the user authentification and other access restrictions by using the <Limit> directive for certain request methods that are used by DAV, but this is really ugly.

� You probably want to allow write permissions to sub-directories above the public DocumentRoot tree to ensure that PHP includes files, Java™ servlets or property files may be deployed to the web application using DAV.

Note: Nevertheless a practicable solution may exist by using just one VirtualHost.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 2: Splitting the VirtualHost

Now we´ll divide the single VirtualHost section defined within the current configuration file conf/vhosts/www.foo.com into two


[...]

</VirtualHost>


[...]

<Directory /home/www/www.foo.com>

DAV On


AllowOverride None

Order allow,deny

Allow from all

</Directory>

[...]

</VirtualHost>

Note: Assuming we have decided that all DAV VirtualHosts should be listening to port 4040 and the appropriate Listen directive has been set within the main configuration file (i.e. httpd.conf).

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


mod_auth (authentification using text files)

To solve the main problem of the previous section this is usually the easiest way. We use Apache´s own constructs for protecting certain <Directory> or <Location> realms against miss-usage and non-authorized access.

This module allows the use of HTTP Basic Authentication to restrict access by looking up users in plain text password and group files.

It´s part of the Apache distribution and is compiled-in by default.

What are the features and what problems does mod_auth solve:

� Implements the use of HTTP Basic Authentification which is specified within HTTP 1.0 and supported by all major HTTP clients.

� Access restrictions for the DAV-enabled zones can be defined using the Require directive and the appropriate entity out of user, group or valid-users.

� Maps users to groups using the AuthGroupFile directive which enables us to give write permissions to the VirtualHosts based upon these groups.

� Text files for the AuthUserFile and AuthGroupFile directive are located on the local file system. If no NFS is used to share these files across several installations you will probably have to maintain each set of these files on every machine.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 3: Including User Authentification (mod_auth)

Now we add user authentification for the <Directory> sections within our DAV VirtualHost by including the following directive to conf/vhosts/www.foo.com

[...]


DAV On


AllowOverride None

Order allow,deny

Allow from all

AuthType Basic

AuthName "WebDAV: www.foo.com"

AuthUserFile /home/www/etc/htpasswd

AuthGroupFile /home/www/etc/htgroups

Require group www.foo.com

</Directory>

[...]

Note: You should notice that HTTP Basic Authentification does not use any kind of encryption for the transmission of the credentials.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Status

After performing step 2, splitting the VirtualHost into two segments and step 3, including user authentification we make the following conclusions

� Access to the DAV enabled VirtualHost is not restricted. Write permissions may be assigned to the individual directory on a group basis.

� There is no security concerning the transmission of the userid and password values yet.� There is no security concerning the IP based connectivity to the DAV VirtualHost.

Currently anyone who is in possession of the credential may manipulate data within the web application. You probably don´t want to enable your developing parties to change things from outside, except you have a lot of home working entities, which is difficult anyway.

� The is also no security concerning transmission of the web application data yet. DAV incorporates no security mechanisms while performing and handling the requests.

� Notice that we have changed the top-level of the VirtualHost directory to one level up. This is used to enable write permissions to directories containing PHP include files, Java™ servlets or property files.

� Make sure your htpasswd and htgroups files are not under the scope of any DAV enabled VirtualHost! After successful login a user may exchange those files and hence exploit the system.

� If no network capable mechanism is used to share the credential files, there is still the need to maintain at least one set of password and group files per installation.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


mod_access (access control based on IP)

Solving the security need to ensure that only developing parties are able to access the DAV VirtualHosts from their working place on an IP based access restriction we use Apache´s own feature for this.

This module provides access control based on client hostname, IP address, or other characteristics of the client request.

It´s part of the Apache distribution and is compiled-in by default.

What are the features and what problems does mod_access solve:

� Implements network connectivity access restrictions for the DAV-enabled zones can be defined using the Allow, Deny and Order directives within the <Directory> section.

� Basically this mechanism refuses brute force attacks to the HTTP Basic Authentification from mod_auth if the attacker is coming from the outside world. Those requests are not handled in terms of checking the credentials.

� Nevertheless denial of service attacks to the URI may be performed.� Remember that mod_access checks every incoming request, which is usually not

very performative for a large-scale production environment.� Consider to use a real firewall which addresses access restrictions on a more lower

network layer level for this task. Then you may leave step 4 out of mind.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 4: Including Access Restrictions (mod_access)

Now we add access restrictions based on IP ranges or client hostnames or domains for the <Directory> sections within our DAV VirtualHost by including the following directive to conf/vhosts/www.foo.com

[...]


[...]

AuthType Basic


AuthUserFile /home/www/etc/htpasswd

AuthGroupFile /home/www/etc/htgroups


Order deny,allow

Deny from all

Allow from bar.com 10.11.12.0/255.255.255.0 10.11.13.1

Satisfy all

</Directory>

[...]

Note: The Satisfy directive is required if both Allow and Require are used.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Status

After performing step 4, including access restrictions we make the following conclusions

� Access to the DAV enabled VirtualHost is now restricted on both user authentification and network address basis.

� There is no security concerning the transmission of the userid and password values yet.� The is also no security concerning transmission of the web application data yet. � Checking IP ranges using mod_access is really slow if you assume high traffic to your

DAV VirtualHosts, especially when the amount of small files is huge.� Use a real firewall for this. This will boost performance concerning IP range checking and

your users won´t complain why this new WebDAV enabled concept is that much slower for transferring their files with FTP.

� Still the credential files aren´t shared, hence maintenance is still to be considered inefficient for our purpose.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


mod_ssl (enabling SSL)

This module provides strong cryptography for the Apache (1.3.x) web server via the Secure Socket Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols by the help of the open source SSL/TLS implementation library OpenSSL. mod_ssl is an Open Source module provided under an Apache-style license. The module was originally derived from Apache-SSL and is written and maintained by Ralf S. Engelschall <[email protected]>.

It´s available at http://www.modssl.org/The required OpenSSL library is available at http://www.openssl.org/

What are the features and what problems does mod_ssl solve:

� Extends Apache‘s API to the Extended API (EAPI) which is required to hook into the request processing and communication layer to enable Secure Socket Layer (SSL) capabilities brought by mod_ssl.

� The module is used to encrypt the communication using SSL between the DAV enabled user agent of the developing parties and the Apache installation serving the DAV enabled VirtualHost zones for the web application deployment.

� Therefore we secure the transmission of our transferred files and ensure that value-critical data like web application logic is not exploit to sniffers on the public net.

Note: This uses strong cryptography, it falls under certain export/import and/or use restrictions in some parts of the world. We´ll assume you have configured and installed the required OpenSSL library on your systems.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Installing mod_ssl

The installation process is slightly different for mod_ssl, even if we intend to compile it as Dynamic Shared Object (DSO) too. The reason therefore is the need to patch Apache´s core source files to enable the EAPI which is needed to place certain hooks for mod_ssl. To patch and configure the package use the following command:

$ cd mod_ssl-2.8.x-1.3.x

$ ./configure --with-apache=../apache_1.3.x

$ cd ..

Now we have to re-configure and re-build the whole Apache suite, this is done by

$ cd apache_1.3.x

$ ./configure --enable-module=ssl --enable-shared=ssl \

[...] more configuration options [...]

$ make

$ make certificate

$ make install

Please refer to the mod_ssl documentation for further information about creating or obtaining certificates, signing certification requests, using self-signed certification request and so on.

The usage of a set of self-signed certificate for the individual machines should be enough.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 5: Adding global SSL directives

Before we add the SSL part in the DAV enable VirtualHost files we have to add some mod_ssl directives to our global VirtualHosts configuration file conf/vhosts.conf

[...]

DAVLockDB /home/www/var/DAVLock

SSLPassPhraseDialog builtin

SSLSessionCache dbm:/home/www/logs/ssl_scache

SSLSessionCacheTimeout 300

SSLMutex file:/home/www/logs/ssl_mutex

SSLRandomSeed startup builtin

SSLRandomSeed connect builtin

SSLLog /home/www/logs/ssl_engine_log

SSLLogLevel warn

SSLCertificateFile /home/www/certs/server.crt

SSLCertificateKeyFile /home/www/certs/server.key


[...]

Note: You may also place these directives to your main configuration file (i.e. httpd.conf) or incorporate them into the specific DAV enabled VirtualHosts if you want to tune things.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 5: Adding SSL to the DAV VirtualHost

Now we add the SSL capabilities mod_ssl provides us with to ensure that any communication to our DAV enabled VirtualHosts on the machine is encrypted. Add the following to the conf/vhosts/www.foo.com file


[...]


[...]

</Directory>

[...]

SSLEngine On

ErrorLog /home/www/www.foo.com/logs/error_log-dav

CustomLog /home/www/www.foo.com/logs/access_log-dav ssl-combined

[...]

</VirtualHost>

Where the custom log scheme ssl-combined is defined within the main configuration file as

LogFormat "%h %l %u %t %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %>s %b \

\"%{Referer}i\" \"%{User-Agent}i\"" ssl-combined

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Status

After performing step 5, adding SSL to the DAV VirtualHost we make the following conclusions

� Any logical network traffic from the DAV enabled clients to the DAV enabled VirtualHosts is now encrypted using SSL.

� Therefore the HTTP Basic Authentification made by mod_auth is also secured using the underlying SSL transport layer.

� If you are really paranoid concerning security you may use explicit client and server certificate handshaking before allowing any connection. This addresses the “man in the middle attack” problem. Please refer to selected documentation concerning SSL for this approach.

� There is still a need to organize the credential files on your independent Apache installations on a global basis. As a maintainer of the write permissions to the specific VirtualHosts you probably want to have your life as easy as possible.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


mod_auth_mysql (authentification using MySQL)

This module will enable your Apache (1.3.x) web server to use a MySQL database server for HTTP Basic Authentification. It uses the MySQL client API to connect to the server and queries if the given username and password credentials are valid within the tables. The module has been contributed by Zeev Suraski <[email protected]>.

It´s available at http://www.mysql.com/Downloads/Contrib/mod_auth_mysql-2.20.tar.gz

What are the features and what problems does mod_auth_mysql solve:

� The features of the mod_auth module can be replaced using this module.� All user credentials and group mapping may be stored to relations within one

database and hence consistency across all Apache installations may be ensured.� There is no need to tweak all sets of text files on the individual machines anymore.� There are several MySQL Graphical User Interface (GUI) for administrating and

maintaining the necessary tables within the database.� We prefer the MyODBC driver which enables you to link MySQL tables to your local

Microsoft™ Access database to perform GUI based maintenance of the data stored within the relations.

� We’ll assume you have a working MySQL database engine installation running on a dedicated host for this purpose.

Note: To achieve the basic concept of sharing the credentials across several Apache installations you may also use other mod_auth_name modules that are available. Consider to use an LDAP module if it fits to your environment.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Installing mod_auth_mysql

The original distribution of the mod_auth_mysql package is quite old and there is a problem concerning an Apache header file dependency which causes an error while re-compiling Apache with the added module. Edit the apMakefile.tmpl file on line 69 to

$(INCDIR)/ap_alloc.h $(INCDIR)/buff.h \

Unfortunately there is also a problem compiling the module as Dynamic Shared Object (DSO). That’s why we will compile it as static module to the Apache core library. To configure and install the module use the following commands:

$ cd mod_auth_mysql-2.20

$ ./configure --with-apache=../apache_1.3.x

$ make

$ cd ../apache_1.3.x

$ ./configure --add-module=src/modules/auth_mysql/libauth_mysql.a \

[...] additional configuration directives [...]

$ make

$ make install

Note: You should compile-in this module before including the DSO capable modules using the APXS tool. Install mod_ssl first, followed by mod_auth_mysql and the DSO modules.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 6: Adding global MySQL directives

The mod_auth_mysql module takes at least one parameter necessary to address the MySQL database server for the global scope within conf/vhosts.conf

[...]DAVLockDB /home/www/var/DAVLock

Auth_MySQL_Info [hostname] [mysql-userid] [mysql-passwd]

[...]include conf/vhosts/www.foo.com[...]

To ensure security you should change permissions within MySQL’s own access restriction facilities using the mysql database and it’s tables

� Create a user (i.e. admin) which for the administration usage (i.e. for connections using ODBC) which has select, insert, update and delete privileges.

� Create a user (i.e. webdav) which is used for the select queries made by the mod_auth_mysql module.

� Make sure only your administrative IP may connect using the user admin and only your Apache installation hosts may connect using the user webdav.

Note: Please refer to the MySQL documentation for further information on how to do this.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Step 6: Changing to MySQL based authentification

Now we replace the previous block introduced within step 3 by the following sequence to the <Directory> section of the DAV enabled VirtualHost within conf/vhosts/www.foo.com

[...]


[...]

AuthType Basic


Auth_MySQL_DB webdav

Auth_MySQL_Password_Table users

Auth_MySQL_Username_Field userid

Auth_MySQL_Password_Field passwd

Auth_MySQL_Group_Table groups

Auth_MySQL_Group_Field vhost

Auth_MySQL_Empty_Passwords Off

Auth_MySQL_Encryption_Tables Plaintext


[...]

</Directory>

[...]

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Status

After performing step 6, changing to MySQL based authentification for the DAV access to the VirtualHost we make the following conclusions

� We are now able to maintain the user credentials and the group based mapping for the access permissions to the specific web applications served by the public VirtualHosts within a MySQL database.

� This may be done using a simple ODBC connection from a Microsoft™ Access client via linking the tables to the local Access database.

� Keep in mind that ODBC communication is not secured, hence if your dedicated MySQL host is not within your own local area network there may be potential exploits of user credentials.

� Use a well configured firewall to protect the MySQL port on which your allowed clients (i.e. the mod_auth_mysql modules) are connecting.

� Except you are using IPSEC tunneling to let your Apache installation hosts communicate to the MySQL host there is no way to ensure MySQL connection security if the MySQL host is not behind a firewall in place where the Apache hosts are.

� You may consider to place the MySQL dedicated host to your ISP, because of two main reasons. It is more likely that your low or medium-bandwidth connection drops and hence other remote parties can’t work on the DAV VirtualHosts than the Ethernet of your ISP. And the ratio of SQL statements send in terms of checking users permissions is usually greater than those for administration purposes.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions



After integrating the modules and their directives into the Apache configuration structure for one single Apache installation we have addressed all problems that have been mentioned while our introduction.

The following figure shows the setup we have generated for the distributed authoring environment for collaborative web application development.

Figure: Apache configuration structure on a single host

vhosts.conf

global directivesm od_davm od_ssl

m od_auth_m ysql

include www.foo.cominclude www.foo.com

include www.foo.com

httpd.conf

main apache configurationdirectives

include vhosts.conf

www.foo.com

VirtualHost www.foo.com:80for public access

VirtualHost www.foo.com:4040for DAV access

Docum entRoot above htdocsDAV access enabledSSL connections only

HTTP Basic Authentification

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions



The following figure shows the system architecture and its components that be build up through step 1 to step 6. You may multiply both the Developer Network block if you have several branches or offices that work collaboratively on web applications and the ISP Network block if there are more than one location hosting your Apache installation hosts.

Figure: System Architecture Overview showing network connectivity

ISP N etw ork

D eveloper N etw ork 10.11.12.0/255.255.255.0

DAV Client

DAV Client

DAV Clientsevera l

ODBCClient

Apache Host

www .foo.comwww .foo.com

public V irtua lH ost

D AV V irtua lH ost

MySQL Host

database w ebdav

tableusers

tablevhost

Apache Host

www .foo.comwww .bar.com

public V irtua lH ost

D AV V irtua lH ost

SQ L Q ueries forH TTP Basic Auth

SQ L Q ueries forH TTP Basic Auth

Internet

D AV connection over SSL

H TTPHTTP Client

O D BC connection

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Using a GUI for administration

You may use several available Graphical User Interface (GUI) to maintain the tables within the appropriate database on your MySQL host.

A very simple but effective way is to use Microsoft™ Access as a ODBC interface. All changes you do within your linked tables are written via the MyODBC driver to the MySQL database and hence there are made in real-time.

Figure: A sample control panel showing the entities for the write permission.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Final Conclusions and Considerations

Now that we have presented our concept for Apache Distributed Authoring for collaborative web application development we want to mention things that are still to be focused on.

� MySQL is a nice storage place for your user credentials. It‘s even more sophisticated if you have build up other systems that use your described world within a database, maybe some kind of intranet data. Otherwise you may consider to use LDAP directories as a state-of-the-art representation.

� Nevertheless if you want to centralize the authentification clearing point (i.e. the MySQL or LDAP dedicated host) you have still the problem that this traffic is usually not encrypted if it uses the public IP network. Consider to use IPSEC, CIPE or other secured VPN technologies for encrypting this logical network connection.

� A centralized solution has the benefit in case of emergency that you may plug-out one machine from your local network and no one will be able to change anything immediately.

� The main benefit assumption is also the worst case if your connection to this authentification server drops and no one is able to work because of it.

� Time based access restrictions and expire dates may be added to the concept so you may ensure that developing parties who finished their work on certain VirtualHost don‘t have any further permissions.

� On heavy loaded Apache installations there may be a bottleneck concerning network and reply speed for the DAV users and the public world. Apache doesn‘t set any kind of priority mechanism for requests that are routed to the DAV enabled VirtualHosts. Consider to use load balancing or throttling techniques for that. See the mod_backhand module available at http://www.backhand.org/ or mod_throttle for this.

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions


Final Conclusions and Considerations (2)

� Versioning of the web application development process or its files is not addressed in any way in the given concept. You will probably want to rely on a revision control system like CVS here.

� At least for the Microsoft™ Windows world there are tools that map WebDAV resources to drives. This is great to transparently DAV enable any kind of application that resides on your local machine. You may check-out from a CVS tree directly to a disk drive which is a WebDAV resource and hence make a deployable check-out without the need of copying.

� There are similar client applications written by Joe Orten <[email protected]> that are available at http://www.webdav.org.

Please keep in mind that the presented concept should be a modeling issue. It may be extended in many ways depending on your real world needs. It is a practicable solution in a real world scenario, reduces maintenance issues for administrators and creates a more sophisticated seamless web application development environments.

Thank you very much for your patience!

Introduction

Scenario


Modules

VirtualHosts


Step1:mod_dav


Step 3:mod_auth

Step 4:mod_access

Step 5:mod_ssl




Final Conclusions

Documents

Copyright © 1998-2001 Stipe Tolj. All rights reserved. Apache Distributed Authoring Environments for collaborative web application development Stipe Tolj