Alex Peshkov wrote:

>Jim Starkey wrote:
>
>
>>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.
>>
>>
>>
>
>Do you talk about server or client side? On client - yes, possible, but
> on server we should anyway pass it to plugin, which initiated exchange.
>
>

Absolutely. The attach, create, and authenticate calls need to be
extended with callback address and argument. The callback signature
should look something like:

int callback (void *arg, int dataLength, const UCHAR *data, int
bufferLength, UCHAR *buffer)

where the actual length of returned data is returned as value. The data
passed back and forth is opaque to everyone but the security plugin and
the client callback procedure.

>
>
>>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.
>>
>>
>>
>
>Once again - on server or client?
>On server callback sends a packet to the client and waits for an answer
>from it.
>
>

Yup. It's on a worker thread on both ends, so it's ok.

>Do you suppose to open additional port for it? I always wanted to use
>existing connection. An in that case all incoming packets are gathered
>by main packets processing cycle, and there is no direct conversation
>possible between server and client.
>
>

No. Same port is OK -- the call is synchronous. The client is waiting
for a return status packet. It gets a callback instead, so it handles
the callback and resumes waiting.

>
>
>>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.
>>
>>
>>
>
>I really don't see, how does it affect client side. Attach handle, which
>is not a database handle, but authentication object handle, is used only
>by remote subsystem, which knows how to talk to client. It absolutely
>doesn't affect the client side.
>
>

The question is how deeply the remote code needs to get involved in
authentication challenges. If you're model of multiple API calls, the
remote code has to have knowledge of the challenge semantics to properly
handle the challenge. This strikes me as highly undesirable. To the
degree possible, the remote interface should be no more than an RPC.
Callbacks allows the plumbing (the remote interface) to be independent
of the semantics (client side processing of the challenge). The
callback mechanism allows alternative trusted authentication schemes to
be implemented as a client layer and a security plugin without impacting
the remote interface and server code. Your scheme requires either a
custom client or a relatively complicated client side plugin to
intercept, process, and return challenges.

>
>
>>
>>
>
>Well, I've already agreed that with Vulcan's remote architecture
>callback is possible. But this solution limits us in a choice of what we
>can do in remote and what can't.
>
>

No, it just means that you have to modify the remote code to meet new
requirements.

Though I am a little confused. I thought the next stretch on the
roadmap was the merge. Are you planning a post FB2 functionality release?

>
>
>>I think we need to decide whether op_trusted_auth is something we want,
>>first. I don't think it is.
>>
>>
>>
>
>I've started with it because was asked by Paul Beach. I.e. it seems that
>there is some commercial need in trusted authentication. And from point
>of common sense this is useful thing, I see nothing bad in it, only
>good. It makes clients life simpler and secure enough. Why not?
>
>

I'm not objecting to the requirements. We all know that the existing
authentication system sucks. I'd rather see a general solution that can
work with the Microsoft architecture for pure Microsoft shops, but
generalizes to general cross platform solution. I think a general
authentication architecture, probably Kerberos, would make a fine
replacement for account/password. Let's solve the general problem, not
just one little piece.

>
>