User store migration (Basic authentication migration)
Apache offers several ways to provide authentication. The most common is Basic Authentication, which is provided by the mod_auth module.
For example the following set of directives protects the /app/docs/private directory.
<Directory "/app/docs/private"> AuthType Basic AuthName "Important people" AuthUserFile /app/apache-ssl/conf/passwords AuthGroupFile /app/apache-ssl/conf/groups Require group privategroup </Directory>
This will only allow access to users of the group privategroup, as defined in the file /app/appache-ssl/conf/groups. The users and their passwords are defined in the file /app/apache-ssl/conf/passwords. This userfile has been created using the utility htpasswd supplied with Apache.
$ /app/apache-ssl/bin/htpasswd -c passwords johndoe
This is how the file looks like:
johndoe:tBI2T6rs1feBY janedoe:TKiOfwywMUW82 jsmith:9PvSsyOvhKpAs akurosawa:4ghYYeyddKr.2 yozu:E25P.WzmKSLL2 sohara:Nja8F.eowQ63c
And this is how the groupfile looks like
privategroup: janedoe akurosawa yozu othergroup: jsmith sohara jonhdoe
The directives that protect the web resource can be put in httpd.conf or an .htaccess file inside the /app/docs/private.
Migrating this user set to SJS Web Server 7.0 is not difficult, as SJS Web Server also provides support for flat password files created using htpasswd. These files can be used as an Authentication Database that can be used by other features of SJS Web Server, for example Access Control Lists. This files can also be used for authentication when using htaccess files.
Follow this steps to create an authentication database using the flat user files.
1. Copy the files to the instance config directory where your configuration is deployed and up to date. (optional). For example:
$ cp passwords /sun/webserver7/https-blogsite-example.com/config/ $ cp groups /sun/webserver7/https-blogsite-example.com/config/
2. Secure the files so only owner can read them. Ensure that the owner is the same user under which the server instance runs, ex. webservd
$ chmod 400 passwords $ chmod 400 groups
4. Pull the new files into the Administration Server's configuration store
wadm> pull-config --config=blogsite-example.com myserver.com CLI201 Command 'pull-config' ran successfully
3. Using the Administration CLI add a new Authentication Database based on the configuration to which you are migrating this users.
wadm> create-authdb --config=blogsite-example.com --url=file myauthdb CLI201 Command 'create-authdb' ran successfully wadm> create-authdb-userprop --config=blogsite-example.com --authdb=myauthdb syntax=htaccess userfile=passwords groupfile=groups CLI201 Command 'create-authdb-userprop' ran successfully wadm> deploy-config blogsite-example.com CLI201 Command 'deploy-config' ran successfully
This results in the following element in server.xml
<auth-db>
<name>myauthdb</name>
<url>file</url>
<property>
<name>groupfile</name>
<value>groups</value>
</property>
<property>
<name>userfile</name>
<value>passwords</value>
</property>
<property>
<name>syntax</name>
<value>htaccess</value>
</property>
</auth-db>
Note that you can also edit server.xml manually, and then pull the changes to the Administration Server's config store using the pull-config command.
Now you can use your new authentication database myauthdb with your ACLs. For example the following ACL protects the /app/docs/private directory, authenticating users using myauthdb.
# config/default.acl
...
acl "path=/app/docs/private";
authenticate (user,group) {
database = "myauthdb";
method = "basic";
};
deny (all)
user = "anyone";
allow (all)
group = "privategroup";
...
Posted by sohbet on July 28, 2007 at 03:11 PM PDT #
Posted by chat on July 29, 2007 at 12:55 AM PDT #
Posted by Sohbet on July 29, 2007 at 06:45 AM PDT #