"Alex Peshkov" <pes@...> wrote:

>
> Fbclient detects that it has no login/password in DPB. Any remote server
> will currently disable user's login in this case. Therefore such state
> of DPB is a reason to try trusted authentication.

This may also mean that the user intended to use ISC_USER/ISC_PASSWORD, but
forgot to set them up. Alternatively, imagine a user which wants to use
trusted authentication, but somebody else has set up the envvars and hence
the connection will be done using the security database authentication.
Wouldn't it be better to allow the user to explicitly specify that he wants
a trusted authentication (via isc_dpb_trusted_auth)? I'd vote for that.

> Client creates
> authentication object (AuthSspi) and gets data from it to send to the
> server. That data is added to the DPB (I've added isc_dpb_trusted_auth
> tag). Server receives such DPB and the first thing it does when finds
> isc_dpb_trusted_auth - removes it from dpb and sends to server's
> AuthSspi object to validate credentials. At this moment server needs to
> send some data to the client and get an answer to this question. To
> implement such data exchange I had to add new packet type
> (op_trusted_auth) with single field - authentication data.

AFAIU, any new packet type should mean a protocol version bump.

> Here I want
> to emphasize that nobody except windows API needs to know the format of
> this bytes - we just transform it over the wire. Server sends a packet
> to the client and waits for an answer from it. In case that everything
> is OK server accepts clients credentials from the answer (there may be
> more than 1 iteration) and knows the windows login name of the remote
> user. It adds isc_dpb_trusted_auth tag to the dpb and now it contains
> remote user's name. I had to modify engine a little to learn SCL_init
> accept user's name from isc_dpb_trusted_auth tag without any validation
> in the security database.

Good.

> As a good results of current approach I'd like to mention:
> 1. It doesn't break remote protocol in any way - exchange with packets
> of new format begin in that and only that case, when both client and
> server understand what is trusted authentication.

What if the older cliend sends isc_dpb_trusted_auth (e.g. I specify it in
DPB manually)? The server will start negotiation with the code which is not
ready to process op_trusted_auth packets. So I think that it should be done
using a new protocol version with the appropriate protection code.
isc_dpb_trusted_auth should be ignored if both the server and the client
don't agree on a protocol version which supports op_trusted_auth.

> 2. It doesn't depend upon internals of authentication objects. Moreover,
> it's easy to have trusted authentication of almost any kind, using
> virtual authentication object - i.e. to have authentication plugins.
> 3. I've tried it with w2k3 server and various clients (starting from
> w98), and I had no problems. I use NTLM credentials, and therefore I
> suppose no problems for older servers, including NT4.
> 4. I don't see problems with this approach in the future firebird 3.

Good.

> What main problem I see - if we decide to have plugins for trusted
> authentication (now everything is inside client/server code, which is OK
> for experimental version), we will have 2 places in firebird for
> authentication plugins. One in fb_authenticate_user() and another in
> remote subsystem.

This doesn't look good, but I don't see a better solution either.


Dmitry