Re: [Firebird-Architect] Re: [Firebird-devel] User semantics vs authentication

[Mark O'D. <mar...@fi...>]

Jim Starkey wrote:
> 
> First, I'd like to ammend my proposal with the addition of
> 
> upgrade user <username> ...
> 

Like seemingly everyone else here, I also like the idea of an SQL
"CREATE USER" command.

But given we already have "recreate table", "recreate procedure" what
about "recreate user" rather than "upgrade user"?

Whatever is chosen it would be good to have a consistant keyword usage.
(we could always do "create or replace user". :-).


> 
> Dmitry proposed handling a user like other database objects and to 
> separate "user name" used in the DDL command and an "identified by" 
> string for logon purposes.
> 

I also think Dmitry's idea of having the ability to store the user in
the database has merit (and as I understand he implemented in a private
tree last year).


> We could define a core system table FB$USERS (folks, we're not rdb
> anymore) with account name as primary key.  All other fields would
> necessarily be defined by whatever security plugin was configured.

The table should only need to support the "internal" passwd hash
mechanism as a default fallback mechanism if not using a plugin.

Plugins are responsible for their own data, and it's unlikely they will
need extra fields in a FB$USER table.  For instance using LDAP, SASL,
and NTLM will store the passwd hash in their own databases.

If needed at all they should probably add a new table.

> For the purpose of discussion, I envision the set of security plugs 
> would include:
> 
> 1. Central security database for backwards compatibility (and 
> somebody even might like it) 2. User/passwords stored in target
> database 3. PAM based for *ix systems 4. NT Domain based for Windows
> systems 5. LDAP based for large organizations

For unix there is PAM which then already has modules for everything else
(including NTLM). so you only need PAM.

Surely, since this is such a smart idea, on windows there is something
similar?


> Someone raised the question as to why the network connection database
>  parameter provided for a list of addresses.  I did this because 
> Interbase/Firebird/Vulcan TCP servers can redirect a connection
> across the network.

Will this be similar to a prior issue where an IP address was passed
back from the server to the client, for the client to make an extra
connection for event processing?  As this can causes havoc when
tunnelling through NATed firewalls.

Curiously Oracle has a similar problem, (I nearly mentioned it last time
this came up). Oracle server has three modes, dedicated server,
preallocated dedicated and multithreaded server.

In all, except for the first, after the server/listener accepts a
connection it passes back to the client a new port/ip address and the
client reconnects using the new port/ip address.  Again this  causes
problems mapping these IPs/ports through firewalls.

NATing firewalls certainly did throw a lemon in the works, invalidating
some of the assumptions with which these protocols were designed :-).


Cheers

Mark