Alex Peshkov wrote:

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

The question of implementation is secondary. The primary question is
how the API should work to best support the functionality required. That
said, I don't see any problem in either implementation. The packet is
recognized as a callback and processed immediately. There is no reason
to route it back to the code that initiated the exchange.

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

The callback doesn't wait on anything -- it's just a function. When the
callback packet arrives, it get called. It's really that simple. Don't
try to make it complicated.

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

The callback mechanism works because it allows an server initiated
conversation between the server and the client as part of the
attach/create call. Passing back a funny status and a partially
functional attach handle that needs additional call to operate strikes
me as a kludge across the board. It totally breaks fb_authenticate_user
and complicates the client side.

The callback mechanism is simple, elegant, and general. It meshes well
with the existing API (extended to pass callback addresses and
arguments). And it allows attach_database, create_database, and
authenticate_user to operate as single calls without the need to drop
into multi-phase operation. It's really the right way to handle the
problem.

>
>
>>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.
>>
>>
>>
>
>Point 3 is definitely the best choice. There may be a number of other
>authentication plugins, except windows NTLM.
>
>

This doesn't need to be decided now.

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

I think we need to decide whether op_trusted_auth is something we want,
first. I don't think it is.

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

That's a good question. But from what I hear, Interbase may be already
more or less dead, in which case the issue is moot.

Anyone want to take up a collection and buy Interbase? We can use the
money left over to have a party.


[Non-text portions of this message have been removed]