Jim Starkey wrote:

> 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.
>
>

> 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.
>

Certainly, placing plugins in engine is more beautiful.

Appears callback will work with Vulcan. I see there major change in
processing of incoming requests. Firebird, when it notices requests
queue at the port, places incoming request in that queue and let's
thread, processing that queue, continue it's work (like it was done in
Vulcan in now commented out processRequest). Obviously, when Firebird
receives packet, returned by client as as answer to callback, it will
lock-up - callback routine waits for an answer from client, that answer
waits for the end of processing previous request, but that request waits
for a callback. I've seen this state of server a few times - first I was
also thinking about callbacks. And even made them run, processing
op_trusted_auth in a special way, but is was a bad hack, breaking remote
architecture - imagine only check for specific op_code in main packets
processing cycle.
If that change of incoming requests processing in Vulcan is permanent,
callback is a real alternative. Though it will require additional
semaphore per port to let callback wait for a packet.

I prefer the alternative of returning status code from attach/create.
This will not require duplicating isc_attach / create / service_start
with callback-enabled appropriate fb_* calls. Only single
fb_trusted_auth to continue authentication, which will call appropriate
continuation routine. What about returning authentication content from
attach / create - we may use counted string in status vector. I don't
see a reason why it cannot hold about 100 bytes of binary data.
Additional 'plus' for return code - it's indendent from remote
architecture. Currently same mechanism works successfully for
INET/XDR/WNET, which were implemented by borland in "slightly" different
manner. And though this is not very important for uniform Vulcan -
independence from other layers is good feature, is not it?

> 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).
>

Point 3 is definitely the best choice. There may be a number of other
authentication plugins, except windows NTLM.

> * 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.
>

Vulcan already has protocol 11 - new fb_authenticate_user and
fb_update_account are implemented in it.
May be it's worth adding op_trusted_auth to version 11?

Related question - should we protect protocol version from same numbers
in Interbase?