By the miracle of TiVO, Ann and I were watching the Westminster Dog Show
last night. One of the fluff pieces was a bit about a Portuguese Water
Dog name Figaro who was helping 2nd grade children learn to read. It
seems that reading out loud is a very good way to both promote reading
skill and a genuine love of reading, but many 2nd graders are deathly
afraid of making a mistake when reading to their classmates, teachers,
or even their parents. But it also turns out that 2nd graders don't
worry making mistakes in front of a dog. Figaro graciously offered his
services as what the behaviorists would call a non-punishing audience.
The kids love to read to Figaro.

As luck would have it, Ann and I also have a Portuguese Water Dog named
Wryly. Wryly has kindly consented to listen to mail about database
architecture. He's already heard a fair bit, because nothing clarifies
an idea of like trying to explain it to a dog. He promises to listen
politely.

So here are some thoughts on database security architecture addressed to
Wryly.

We currently have a hardcoded authentication manager who talks to a
local security database for authentication data. This model doesn't
work for many applications. The obvious alternative is a security
plugin. This would give administrators a choice of policies, including
the option to roll their own. There are three basic types of
authentication systems:

1. Policies that use non-database authentication data such
/etc/passwrd or NT domain authentication
2. Policies that store authentication data in the target database
3. Policies that store authentication data in a different database

In addition, a security manager could reasonably expected to get involved in

1. File open, so a database could be kept on a password protected or
encrypted volume
2. Physical read and writes, so physical data can be encrypted at the
page level
3. TCP connections, to enable use of SSL between the client and server

So looking at a security plug as just an authentication manager is
probably a bit short sighted.

But we need to look at security requirements beyond just authentication
and database file access. Authentication is based on shared secrets
between the client and server. The the moment the "remote provider"
looks at the database parameter block, and if user name and password
aren't specified, performs the highly secure getenv() call to pick the
database username and password, which it then appends to the database
parameter block for transmission to the server. (Wryly is trying hard
not to giggle.)

It would seem that the ability to specified a client-side security
plugin to gather local authentication data for transmission to the
server is also necessary. Having intelligence at either end would
enable a secure "shared secrets" authentication cache on the client
side, transmitted using public key encryption or to piggyback on any
available network authentication mechanisms. (Wryly is pretending to be
asleep, but his inner tail is wagging.).

Going back to the server, a problem that needs to be solved to support
per-database authentication data is a way to give the security plugin
call level access to the database. The existing global API is pretty
much out of the question since they necessarily loop back around through
the Y-valve. A properly encapsulated API, such as the JDBC based IscDbc
interface, is pretty much required to give special access into a
partially opened database.

An endemic problem with the security database idea is controlling access
to the security database itself. The existing scheme is based on
assumption that the security database is running in the same address
space as the target database and can recognize special attachments by
recognizing the address of a handle. Failure to do so would result in
an infinite recurse as the security database invokes itself to check
access to itself. This scheme depends on non-architectural artifacts of
the Y-valve implementation and precludes use of network wide security
databases. An alternative would be to requires the security database to
use a different security plugin.

The Vulcan configuration file systems makes it easy to design the
mechanism for specification of and parameters for security managers on a
per-database basis, so all sorts of specialized schemes are possible and
probably even desirable.

So what we need before we start designing APIs is a clear understanding
of the end-to-end requirements for a robust, secure, extensible security
architecture.

Wryly, any thoughts?

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376