Pardon me for joining the conversation late, but the affairs of running
a small software company from time to time take precedence.

Here is the quickie executive summary of what follows:

1. The attach database call is extended for a challenge callback.
2. The transmission layers -- dispatch, remote, and server -- are
extended to honor the callback.
3. The trusted authentication security plugs issues challenges
through the callback to the client.


Alex Peshkov wrote:

>Taking into account all said, it seems reasonable to locate most of
>related stuff in remote subsystem - interface.cpp for client and
>server.cpp for server. Name of authenticated used is passed later to the
>engine using special DPB tag. This makes absolutely no problems in fb2
>monolyth, but I've initially worried about this from vulcan POV - it
>means that any user can send SYSDBA login in such tag. But as soon as
>any authentication is generally useless for embedded access, this is not
>a real problem.
>
>

Reasonable, perhaps. But not optimal. In our architecture,
authentication and security is the responsibility of the database engine
based on policy established by the configuration. The remote
interface/server are transparent transmission layers without
intelligence. In specific, authentication is performed by configurable
security plugins that do the grunt work. The role of the remote
interface and server is to collect environmental information, package
this information into the database parameter block, deferring policy
questions to competent authority somewhere down the line.

The ability for the server to issue challenges to the client is an
excellent strategy for remote authentication, and one we must learn to
support. It will require extension to the API and to the remote
protocol. There are a number ways to go. One is to extend the
isc_attach_database and isc_create_database calls to include a callback
addresss. A minor variant is to specify the callback in the DPB
itself. The major alternative is a return code from attach/create
indicating additional dialog is required. Since we don't have good
provision for returning semantically rich content from
isc_attach_database and isc_create_database, I am more comfortable with
the callback mechanism.

The order of battle should be something like this:

1. The client calls isc_attach_database.
2. The attachDatabase method in the remote provider (or heirs or
assigns) determines whether or not trusted authentication is
configured. If so, it packages local identity information into
the database parameter block and sends it down the wire (so to speak).
3. The remote server notices the trusted user authentication
information in the DPB. If appropriate, it uses its connection
information to identify the client machine, validates it, and adds
it to the DPB. Some schemes may validate that a remote client is
part of a trusted set of machines; the more sophisticated probably
won't. The server passes the attachDatabase call to the local
isc_attach_database.
4. The display module routes the attachDatabase to a local engine.
5. The local engine calls authenticateUser the security plugin at the
head of the security plugin chain. This, presumably, is the
trusted authentication plugin.
6. The trusted authentication security plugin examines the
credentials and determines whether or not a challenge is
required. If so, it invokes the callback.
7. The callback ultimately gets back to the remote server. The
server packages the challenge information and send it back to the
remote interface.
8. The remote interface (still waiting for the attach_database to
respond) get the challenge packet and performs a callback.
9. Whoever initiated the trusted authentication (more on this later)
receives the callback, gather the necessary and appropriate
information, and returns the data implicitly or explicitly.
10. When the callback returns to the remote interface, it packages the
information into a packet which it sends back to the server.
11. When the server receives the challenge return, it returns to,
ultimately, to the trusted authentication security plugin.
12. When the trusted authentication security plugin receives the
challenge return, it either authenticates the user, or passes the
authentication request, DPB and all, to the next security plugin
in the daisy chain. If no configured security plugin
authenticates the user, the user gets bounced.

The key to this and most other architectures is that each piece is
simple and dumb. Nobody really sees the big picture. An analog is a
cathedral. A cathedral is made of extremely stupid pieces of stone.
Each stone has two responsibilities: Keep the weather out and hold up
the stones above it. In our architecture, the transmission layers
transmit and the security plugin authenticates.

A remaining question is how the client side of trusted authentication is
performed. The order of battle above described the plumbing only. I
can think of three possibilities, none of which are mutually exclusive.
They are:

1. A layer on fb_attach_database (which is isc_attach_database plus a
parameter for a security challenge callback).
2. An extension to the remote interface itself
3. Provision for configurable attach filters in the client.

Any would do; all might be overkill (or maybe just staged integration).

Some short answers to secondary questions:

* Of course account/passed and trusted authentication can co-exist.
Which work and which takes precedence is determined by the
configuration of the engine security plugin chain.
* If the client is configured both trusted authentication, it
provides both account/password and trusted authentication
information in DPB since it can't possible know what security
policies are in effect on the server.
* If you extend the remote protocol, of course you change the
protocol version number. That, dummy, is the reason that there
*is* a remote protocol version number. If anyone on this project
ever masters idea of version numbers to manage backward
compatibility, we're going to send them to the Apache project to
spread the word.