Migrating SunONE Web Server To Apache HTTPD Server

Migrating SunONE Web Server To Apache HTTPD Server

This article describes how to migrate from the SunONE Web server to the Apache HTTPD server. This can be relatively simple and will depend on the complexity of your SunONE implementation. Most all of the web server specific features available in SunONE have counterprarts in the Apache HTTPD server environment.

Note: Please note that UNIX file system is assumed throughout this document.

Migration Planning

You will need to plan to collect and migrate the following information from your SunONE environment (most of the information required is specified in the SunONE server.xml file):

• Virtual servers
• Listen sockets
• Custom response files
• Additional document directories
• CGI directories
• Any custom server side content
• SSL Server certificates cannot be migrated
• ACLs cannot be migrated
• Java web applications cannot be migrated to Apache HTTPD

Configuration Files

Configuration operations for the Apache HTTPD server require editing the configuration files with a text editor and applying the appropriate configuration directives. There is no administration GUI for Apache HTTPD.

SunONE web server configuration files

• magnus.conf – Server wide application level settings
• obj.conf – Server wide NSAPI application configuration settings
• server.xml – Virtaul server configuration parameters, listen sockets, Java settings

Apache HTTPD configuration files

• conf/httpd.conf - All of the server level (global) and non-SSL related configuration directives
• conf/ssl.conf (v2.0.x) - All of the SSL related directives for SSL virtual hosts
• conf/extra/* (v2.2.x) - In v2.2.x feature specific configurations files were created and referenced in the conf/httpd.conf. This made it a little easier to enable/disable specific functionality

Virtual Web Servers

Both SunONE and Apache HTTPD support the configurations of SSL and non-SSL virtual web servers. The SunONE virtual server information is represented in the server.xml file and this information can be used to implement the virtual server configurations in the Apache configuration file (httpd.conf or other).

Virtual Server Classes

SunONE web server provides the capability to group virtual servers such that all virtual servers in a class can use the same obj.conf configuration file and the same listen socket.

Apache HTTPD does not have any direct implementation of virtual server classes.

Listen Sockets

SunONE binds the HTTP/HTTPS listener to a “Listen Socket” which is configured as an IP-Address/Port pair and identified with a name that is referenced by virtual server classes.

Apache HTTPD provides the “Listen IP:port” configuration directive which binds the HTTP/HTTPS listener to a socket and is defined in the configuration file (httpd.conf or ssl.conf).

Listen Socket (SSL)

SunONE provides a special parameter to the listen socket element which specifies that the listen socket is configured for SSL encrytion. The confiruration parameter “security=true” conmfigures the listen socket for SSL.

Apache HTTPD uses configurations directives in the virtual server configuration to engage SSL encryption.

URLHost

SunONE uses the configuration directive “urlhosts=myserver.domain.com” to define the host header name for the virtual.

Apache HTTPD uses the “ServerName” directive to configure the URL host name of the virtual server.

DocRoot

SunONE uses the configuration directive “docroot=/var/www” to define the filesystem location that contains files served by the virtual server.

Apache HTTPD uses the “DocumentRoot /var/www” to define the filesystem location.

Example (Simplified) Virtual Server Configuration

This excerpt from a SunONE configuration (server.xml) file defines a listen socket on port=80 and a virtual server with a urlhost=myserver.domain.com and a docroot=/www/docs.

This exceprt from an Apache HTTPD configuration (httpd.conf) defines the same virtual server:

Listen 80

ServerName myserver.domain.com

DocumentRoot /www/docs

SSL Encryption

The SunONE SSL Server certificate, CA Certificate and other encryption configuration information are incompatible with Apache HTTPD and cannot be directly migrated. You should expect to obtain new SSL server certificates for all of your SunONE SSL servers.

Content Repositories

SunONE and Apache HTTPD both provide several configuration options and capabilities for defining content repositories in the web server implementation.

Document Root Directory

SunONE web server provides the ability to specify the main content repository for the entire web service or each virtual web server.

Apache HTTPD provides the “DocumentRoot /www/docs” configuration directive which can be global to the web service or specified in the “” container. 

Additional Document Directories

SunONE web server provides the ability to specify content directories which are outside of the docroot directory with an assigned URL.

Apache HTTPD provides the “Alias /foo /home/www/foo” configuration directives.

User Directories

SunONE web server provides the ability to specify user owned content repositories.

Apache HTTPD provides the “UserDir public_html” directive to allow users to place content in their “public_html” directory and reference the content using the “~user/mypage.html” URL. 

Program Directories

SunOne web server provides the ability to specify filesystem directories where program scripts are allowed to be located and run. You can have a single “cgi-bin” directoty or othere directories where program handlers run scripts.

Apache HTTPD provides the “ScriptAlias /cgi-bin /var/www/cgi” directive to assign CGI runnable status to objects in a directory. Apache also provides the “Option +ExecCGI” directive which can be used in any “” container to allow CGI programs to execute. 

Java Web Applications

The SunONE Web Server directly implements support for Java Servlets and Java Server Pages however the Apache HTTPD is a web server only and does not provide any direct support for Java web applications.

If you have Java web applications you will need to independently migrate the Java applications to a suitable Java/J2EE container such as Tomcat, JBoss or WebSphere. Apache HTTPD does provide mechanisms for connecting Java web application client requests to Tomcat or JBoss

Migrating SunONE Web Server To Apache HTTPD Server, Migrating SunONE Web Server To Apache HTTPD Server

Integrating Apache with Weblogic & Websphere

Integrating Apache with Weblogic & Websphere

Below is the example of integrating apache with weblogic admin console page…

1. Goto WL_HOMEServerbin and locate the file (where WL_HOME is the Weblogic installation directory)

mod_wl_20.so (Regular Strength encryption)
mod_wl28_20.so (128 bit encryption)

2. Goto APACHE_HOMEmodules directory and copy the above file(s)

3. The Apache HTTP Server Plug-In will be installed in your Apache HTTP Server Installation as an Apache Dynamic Shared Object (DSO) which is based on mod_so.c. Make sure it is enabled (By default it should be enabled) by executing the command below.

APACHE_HOMEbinapache -l (You should see mod_so.c in the output).

4.Edit the Apache httpd.conf file in APACHE_HOME/conf directory and add these lines

#Weblogic configuration details

LoadModule weblogic_module modulesmod_wl_20.so

#Location tag is added only for proxy support by path
#It will take precedence when proxying by MIME type
#is also enabled

SetHandler weblogic-handler
PathTrim /weblogic

WebLogicHost Weblogic host ip
WebLogicPort 7001
MatchExpression *

5. Test the syntax of the httpd.conf file using the command

APACHE_HOMEbinapache -t (You should see SYNTAX OK as output).

6. Restart Weblogic and Apache.

Now if you type

http://apachehostip , it should lead to the Weblogic home page (provided the definition was not there, else it will take precedence and instead of http://apachehostip you have to type http://apachehostip/console/ to see the Weblogic Home Page).

Steps for Apache with Web logic using mod_proxy:

From Apache side:

Edit the httpd.conf file in the /conf directory

Add the following lines:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

#Here Apache and Web logic are running in the same machine.
#Change the IP address to x.y.com if Weblogic is running in a
#different box

NameVirtualHost apachehostip:80

#Here Apache is configured as a proxy server

ProxyPass / http://weblogichostip:7001/
ProxyPassReverse / http:// weblogichostip:7001/

#The default listening port for BEA Web logic application server is 7001

Now if you type

http://apachehostip it should lead to the Weblogic home page.

Integrating Apache with Weblogic & Websphere, Apache integrate with weblogic and webshpere, integrate weblogic with apache, intergrate websphere with apache, integrating apache with weblogic, integrating apache with websphere

Integrating Apache 2.x with IBM Web sphere 5.1 x and above

Integrating Apache 2.x with IBM Web sphere 5.1 x and above

1. Download the Web server plugins for Websphere 5.x from

http://www-1.ibm.com/support/docview.wss?uid=swg24007227 for (5.1x)

http://www-1.ibm.com/support/docview.wss?uid=swg24007265 for (5.0x)

2. Get the file mod_was_ap20_http.dll from the plugin and copy it in

Apache modules directory i.e /modules directory.

3. Get the plugin-cfg.xml (from Websphere) file

This can be got by

1. Running the command GenPluginCfg in the

bin directory (GenPluginCfg.bat)
(where WAS_ROOT is the Websphere Application Server installation directory)

The Plugin-cfg.xml file will be created in the location

configcellsplugin-cfg.xml

2. Running Websphere admin console and exporting the plugin.

Login to the admin console (at port 9090 i.e webspherehostip:9090) (This doesn’t require a user ID or a password)

Goto Environment -> Update Web Server Plugin

Click OK to update the plugin configuration file.

The Plugin-cfg.xml file will be created in the location below

configcellsplugin-cfg.xml

4. Copy the plugin-cfg.xml file in Apache modules directory
i.e /modules directory.

5. Add these lines in the httpd.conf file in the /conf directory.

LoadModule was_ap20_module modules/mod_was_ap20_http.dll
WebSpherePluginConfig modules/plugin-cfg.xml

6. You can change the location of the log file generated by the plugin by editing the plugin-cfg.xml file. For example, if the Plugin
error log is to be generated in the apache logs directory, the plugin-cfg.xml file can be edited as follows.

logshttp_plugin.log”/>

A simplified form of the plugin-cfg.xml file is shown below.

logshttp_plugin.log”/>

7.Now restart Websphere and Apache server and type

http://apachehostip/snoop and you can see the Websphere’s snoop servlet in the browser.

Steps for Apache with IBM Web sphere using mod_proxy:

From Apache side:

Edit the httpd.conf file in the /conf directory

Add the following lines:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so

#Here Apache and Web logic are running in the same machine.
#Change the IP address to x.y.com if Websphere is running in a
#different box

NameVirtualHost apachehostip:80

#Here Apache is configured as a proxy server

ProxyPass / http://webspherehostip:9080/
ProxyPassReverse / http:// webspherehostip:9080/

#The default listening port for IBM Websphere application server is 9080
#If you want to proxy requests for admin console, use 9090 instead.

Now restart the Apache server and type

http://apachehostip/snoop

and you can see the Websphere’s snoop servlet in the browser.

Integrating Apache 2.x with IBM Web sphere 5.1 x and above

How to use User Authentication for Apache

How to use User Authentication for Apache

Using User Authentication

There are two ways of restricting access to documents: either by the hostname of the browser being used, or by asking for a username and password. The former can be used to, for example, restrict documents to use within a company. However if the people who are allowed to access the documents are widely dispersed, or the server administrator needs to be able to control access on an individual basis, it is possible to require a username and password before being allowed access to a document. This is called user authentication.

Setting up user authentication takes two steps: firstly, you create a file containing the usernames and passwords. Secondly, you tell the server what resources are to be protected and which users are allowed (after entering a valid password) to access them.

Creating a User Database

A list of users and passwords needs to be created in a file. For security reasons, this file should not be under the document root. The examples here will assume you want to use a file call users in your server root at /usr/local/etc/httpd.

The file will consist of a list of usernames and a password for each. The format is similar to the standard Unix password file, with the username and password being separated by a colon. However you cannot just type in the usernames and passwords because the passwords are stored in an encrypted format. The program htpasswd is used to add create a user file and to add or modify users.

htpasswd is a C program that is supplied in the support directory of the Apache distribution. If it is not already compiled, you will to compile it first. Run

  make htpasswd

in the support directory to compile it (you might need to modify the Makefile first, since any configuration you did when compiling the server itself is not available to this makefile). After compilation, you can either leave the htpasswd binary where it is, or move it to a directory on your path (e.g. /usr/local/bin). In the former case, you will need to remember to give the full pathname to run it. The examples here will assume that it is installed somewhere on your path.

Using htpasswd

To create a new user file and add the username “martin” with the password “hampster” to the file /usr/local/etc/httpd/users:

   htpasswd -c /usr/local/etc/httpd/users martin

The -c argument tells htpasswd to create new users file. When you run this command, you will be prompted to enter a password for martin, and confirm it by entering it again. Other users can be added to the existing file in the same way, except that the -c argument is not needed. The same command can also be used to modify the password of an existing user.

After adding a few users, the /usr/local/etc/httpd/users file might look like this:

martin:WrU808BHQai36

jane:iABCQFQs40E8M

art:FAdHN3W753sSU

The first field is the username, and the second field is the encrypted password.

Configuring the Server

To get the server to use the usernames and passwords in this file, you need to configure arealm. This is a section of your site that is to be restricted to some or all of the users listed in this file. This is typically done on a per-directory basis, with a directory (and all its subdirectories) being protected (Apache 1.2 and later also let you protect individual files). The directives to create the protected area can be placed in a .htaccess file in the directory concerned, or in a section in the access.conf file.

To allow a directory to be restricted within a .htaccess file, you first need to ensure that the access.conf file allows user authentication to be set up in a .htaccess file. This is controlled by the AuthConfig override. The access.conf file should include AllowOverride AuthConfig to allow the authentication directives to be used in a .htaccess file.

To restrict a directory to any user listed in the users file just created, you should create a .htaccess file containing:

  AuthName “restricted stuff”

  AuthType Basic

  AuthUserFile /usr/local/etc/httpd/users

  require valid-user

The first directive, AuthName, specifies a realm name for this protection. Once a user has entered a valid username and password, any other resources within the same realm name can be accessed with the same username and password. This can be used to create two areas which share the same username and password.

The AuthType directive tells the server what protocol is to be used for authentication. At the moment, Basic is the only method available. However a new method, Digest, is about to be standardised, and once browsers start to implement it, digest authentication will provide more security than the basic authentication.

AuthUserFile tells the server the location of the user file created by htpasswd. A similar directive, AuthGroupFile, can be used to tell the server the location of a groups file (see below).

These four directives have between them tell the server where to find the usernames and passwords and what authentication protocol to use. The server now knows that this resource is restricted to valid users. The final stage is to tell the server which usernames from the file are valid for particular access methods. This is done with the require directive. In this example, the argument valid-user tells the server that any username in the users file can be used. But it could be configured to allow only certain users in:

  require user martin jane

would only allow users martin and jane access (after they entered a correct password). If user art (or any other user) tried to access this directory – even with the correct password – they would be denied. This is useful to restrict different areas of your server to different people with the same users file. If a user is allowed to access the different areas, they only have to remember a single password. Note that if the realm name differs in the different areas, the user will have to re-enter their password.

Using Groups

If you want to allow only selected users from the users file in to a particular area, you can list all the allowed usernames on the require line. However this means you are building username information into your .htaccess files, and might not been convenient if there are a lot of users, and . Fortunately there is a way round this, using a group file. This operates in a similar way to standard Unix groups: any particular user can be a member of any number of groups. You can then use the require line to restrict users to one or more particular groups. For example, you could create a group called staff containing users who are allowed to access internal pages. To restrict access to just users in the staff group, you would use

  require group staff

Multiple groups can be listed, and require user can also be given, in which case any user in any of the listed groups, or any user listed explicitly, can access the resource. For example

  require group staff admin

require user adminuser

which would allow any user in group staff or group admin, or the user adminuser, to access this resource after entering a valid password.

A group file consists of lines giving a group name followed by a space-separated list of users in that group. For example:

  staff:martin jane

  admin:art adminuser

The AuthGroupFile directive is used to tell the server the location of the group file. Note that the maximum line length within the group file in about 8000 characters (actually 8kB). If you have more users in a group than will fit within that line length, you can have more than one line with the same group name within the file.

Problems with Large Numbers of Users

Using htpasswd to create a text list of users, and maintaining a list of groups in a plain text file is relatively easy. However if the number of users becomes large, the server has a lot of processing to do to find a user’s group and password details. This processing has to be done for every request inside the protected area (even though the user only enters their password once, the server has to re-authenticate them on every request). This can be slow with a lot of users, and adds to the server load. Much faster access is possible using DBM format files. This allows the server to do a very quick lookup of names, without having to read through a large text file. However managing DBM files is more complex. Apache Week will cover the use of DBM authentication in a future issue.

Other Ways of Storing User Details

While Apache by default can only access user details in plain text files, various add-on modules are available to allow user details to be stored in databases. Besides DBM format (available with the mod_auth_dbm module), user and group lists can be stored in DB format files (with mod_auth_db). Or full databases can be used, such as mSQL (with mod_auth_msql), Postgres95 (mod_auth_pg95) or any DBI-compatible database (mod_auth_dbi).

It is also possible to have an arbitrary external program check whether the given username and password is valid (this could be used to write an interface to check against any other database or authentication service). Modules are also available to check against the system password file, or to use a Kerberos system. See the feature on Adding Modules for more information.

Limiting Methods Differently

In the example .htaccess file above, the require directory is not given inside a section. This is valid in Apache, and means it applies to all request methods. In other servers and most example .htaccess files, the require directive is given inside a section, such as this:

 

  require valid-user

 

In Apache it is better to omit the and lines, to ensure that the protection applies to all methods. However, this format can be used to limit particular methods. For example, to limit just the POST method, use

  AuthName “restrict posting”

  AuthType Basic

  AuthUserFile /usr/local/etc/httpd/users

 

  require group staff

 

Now only members of the group staff will be allowed to POST. Other users (unauthenticated) can use other methods, such as GET. This could be used to allow a CGI program o be accessed by anyone, but only authorised uses can POST information to it.

Restricting By Hostname or Username

It is possible to use both username and hostname restrictions at the same time. Normally Apache will require that both restrictions are satisfied, that is, that the user comes from an allowed host or domain name and that they supply a valid username and password. However the Satisfy any directive can be used in the .htaccess file or , or , section. When this directive is given, anyone coming from the allowed domains will be given access without having to enter a username and password. All other users (from the “denied” domains) will be prompted for a username and password.

How WWW Authentication Works

The method used in HTTP for user authetication is quite simple. Since HTTP is a stateless protocol – that is, the server does not remember any information about a request once it has finished – the browser needs to resend the username and password on each request. Here is how it works.

On the first access to an authenticated resource, the server will return a 401 status (“Unauthorized”) and include a WWW-Authenticate response header. This will contain the authentication scheme to use (at the moment, only Basic is allowed) and the realmname. The browser should then ask the user to enter a username and password. It then requests the same resource again, this time including a Authorization header which contains the scheme name (“Basic”) and the username and password entered.

The server checks the username and password, and if they are valid, returns the page. If the password is not valid for that user, or the user is not allowed access because they are not listed on a require user line or in a suitable group, the server returns a 401 status as before. The browser can then ask the user to retry their username and password.

Assuming the username and password was valid, the user might next request another resource which is protected. In this case, the server would respond with a 401 status, and the browser could send the request again with the user and password details. However this would be slow, so instead the browser sends the Authorization header on subsequent requests. Note that the browser must ensure that it only sends the username and password to further requests on the same server (it would be insecure to send those details if the user moved onto a different server).

The browser needs to remember the username and password entered, so it can send them with future requests from the same server. Note that this can cause problems when testing authentication, since the browser remembers the first username and password that works. It can be difficult to force the browser to ask for a new username and password.

Security and Digest Authentication

While authentication does allow resources to be restricted to particular users, there are potential security issues. Some of these are:

• Care must be taken to ensure that the resource is restricted against all methods. Use of , for instance, leaves POST and other request methods unprotected.
• The username and password are stored in a plain text file. While the password is encrypted, it is not completely safe against decryption, so the file should not be accessible to other users on the system. More importantly, it should not be placed under the document root where users from other sites could access it.
• The username and password is as secure as any username/password system, in that end-users should not tells others their password, or write it down, or make it easily guessable.
• The Basic authentication scheme transmits passwords across the Internet unencrypted, so they could be intercepted. The Digest method, see below, is intended to address this issue.

The Digest Authentication scheme will make the sending of passwords across the Internet more secure. It effectively encrypts the password before it is sent such that the server can decrypt it. It works exactly the same as Basic authentication as far as the end-user and server administrator is concerned. The use of Digest authentication will depend on whether browser authors write it into their products. Apache can already do Digest authentication, when compiled with the mod_digest module (supplied with the Apache distribution). 

How to use User Authentication for Apache, User authentication for apache, apache user authentication