Our stopgap plan for the journal authentication problem is now to apply simple authentication with a single user/pw at our end, and then have the IALLT proxy draw content from our server using that authentication, while serving out to end users based on authentication against the IALLT users database.

In order to do this, we had to get basic authentication working on Tomcat/Cocoon, which Greg and I have spent the morning figuring out. Predictably, this is not clearly documented, and you have to hack around a bit to figure it out.

Throughout this documentation, I'll use a fictitious user "fred" with a password "bloggs", and a role "nerd".

The first thing you need to do is to edit the tomcat-users.xml file, in [tomcat]/conf. Add a new role, and a new user/password to go with it:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="manager"/>
[...]
  <role rolename="nerd"/>
  <user [...]/>
  <user [...]/>
  <user username="fred" password="bloggs" roles="nerd"/>
</tomcat-users>

This gives you a user and a role you can then use in the web application. Next, you need to edit the webapp's web.xml file in [tomcat]/webapps/[app_name]/WEB-INF. First, find the first <servlet> tag inside <web-app>, and add this at the end of it:

  <security-role-ref>
    <role-name>nerd</role-name>
    <role-link>nerd</role-link>
  </security-role-ref>

This enables Cocoon to be configured to use that role when specifying security constraints. Now we need to specify those constraints. Find the closing </web-app> tag at the end of the file, and add this just before it:

  <security-constraint>
    <web-resource-collection>
      <web-resource-name>[Name of your web application]</web-resource-name>
      <url-pattern>/*</url-pattern>
      <url-pattern>/[whatever]/*</url-pattern>
      <http-method>GET</http-method>
    </web-resource-collection>

    <auth-constraint>
      <role-name>nerd</role-name>
      </auth-constraint>
  </security-constraint>

  <!-- Define the Login Configuration for this Application -->
  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>[Name of your web application]</realm-name>
  </login-config>

  <!-- Security roles referenced by this web application -->
  <security-role>
    <description>
      The role that is required to log in to the application
    </description>
    <role-name>nerd</role-name>
  </security-role>

Save, upload to the server, and restart Tomcat (or just Cocoon, if you've already restarted Tomcat so it reads the users file). Any user name belonging to the "nerd" group can now log in and see the materials protected in this way.

Later note on restarting Tomcat: We tried restarting Tomcat (in this case, tomcat-dev), logged on as me using sudo on the init script as documented elsewhere. This generated a problem we have seen before: the running instance of tomcat-dev failed to stop, and when a new process was started, we ended up with two running. The only way we could find to solve this was to su to hcmc (under which the processes run), and kill both of them. The first (the new one) was effectively killed with just kill, but the other required kill -9. Once both were stopped, we were able to run the init script (as me, using sudo), and Tomcat restarted. Greg is asking sysadmin to figure out what the problem might be here; we've encountered it several times now.