Jackdaw and Raven

2019-04-16 - Progress - Tony Finch

I've previously written about authentication and access control in the IP Register database. The last couple of weeks I have been reimplementing some of it in a dev version of this DNS web server.

Jackdaw

Jackdaw is a complicated beast with a long history.

Back in the distant past when dinosaurs roamed the land), Jackdaw was a graph/network database management system written in BCPL for the IBM mainframe Phoenix. (Philip Hazel has written a bit about the old Jackdaw in his memoir.) It supported a number of uses, including the user admin database.

Before Phoenix was decommissioned in 1995, a new Jackdaw was created using Oracle, initially just for the user admin database. The IP Register database was added in around 2000-2002. (It is actually just a schema within the same overall database.)

As well as the database, Jackdaw has a mod_perl framework for developing web applications on Oracle called WebDBI. The IP Register web UI is one of these applications.

Layers of indirection

Some of Jackdaw's complexity is because it suffered from the 1990s problem of not enough computers, so it is designed to support flexible testing on a single server:

• There are multiple instances of Oracle, of potentially different versions, such as jackdaw, jdawtest, jdawdev, etc.

• There are production and test instances of the web server, running on different ports. The choice of web server also determines the version of the mod_perl framework libraries.

• There are production and test instances of the web applications, selected using an extended URL path.

The exact boundary between what is framework code and what is application code is somewhat murky to me, and I have not found it very easy as relatively unprivileged user of Jackdaw to use this testing setup.

Authentication options

As well as the various prod / test switches, there are a number of configuration variables that depend on which part of the web site you are looking at:

• Is anonymous access allowed? This is used for things like the old email address search page.

• Are long-term cookies allowed? They are used for automated access to the IP Register database.

• Which authentication realm? This is used to tie long-term cookies to particular applications.

Separately, the IP Register UI has its own bodged TOTP two-factor authentication for privileged users, which is separate from Jackdaw's authentication system.

And more

Jackdaw has its own HTTP request dispatch logic which implements the prod / test switch and the authentication process. It also determines whether the request is served by Perl code or by a file on disk, rather than using Apache's own configuration to do this.

I needed to work through all these details to understand how to get it working on another web server, so that I can move the IP Register web interface off Jackdaw while still using Jackdaw's Oracle database.

Simplifying

I have stripped down the code a lot while moving it to my web server.

The reason for moving the web front end is to make it easier to replace the Oracle back end with Postgres. So it is helpful to have less complexity.

So I have removed most of the code to implement the various options I've listed above. The only configuration that is still required is which Oracle instance to connect to, which is now fixed alongside the prod / test / dev options by the Ansible playbooks, and no longer chosen dynamically.

Together with my colleague Ujjwal Das who is responsible for Jackdaw, we have also somewhat simplified the authentication between the web server and Oracle. On Jackdaw, the web server switches between the www and raven_user Oracle users. The new web server only has a wwwdns user.

The www user allows unauthenticated access to a few very restricted parts of the user admin database, and it can run a stored procedure to verify authentication responses from Raven and set up login sessions. For users with login cookies, the server changes to raven_user and runs another stored procedure checks the cookie and sets a sys_context('raven', 'user') variable to identify the logged-in user; this is used by the IP Register database views for access control.

The wwwdns user has no anonymous access to the database, except for Raven login stored procedures. So it is less privileged than the web server on Jackdaw wrt the user admin parts of the databse. This change means that I could not have used Jackdaw's code verbatim even if I wanted to.

Next

The rough plan is to finish the authentication support:

• long-term cookie management

• TOTP two-factor authentication

Then bring over the IP Register user interface. There will be a bit of a reskin but it will still have the same unfriendly behaviour.