Re: [Firebird-devel] User semantics vs authentication

[Jim S. <ja...@ne...>]

Rather than respond individual to so many interest posts, let me batch 
some comments.

First, I'd like to ammend my proposal with the addition of

    upgrade user <username> ...

The "upgrade user" command is syntactically parallel to "create user", 
and is semantically equivalent to "alter user" if the named user exists 
and semantically equivalent to "create user" if not.  The upgrade form 
allows a single script to both create and update accounts.

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.

Other database objects (tables, fields, triggers) are defined in core 
system tables.  It seems obvious that users/accounts should be handled 
this way.  There seems broad consensus that authentication should 
delegated to a security plugin, and different security plugins will have 
different ideas of what should be stored in a system table.  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.  Defining a system 
table with one known field and an unknown number of other fields just 
doesn't feel satisfying.  If someone could come up with a scheme that 
was both useful and open-ended, I could be convinced otherwise, but for 
now, an architecturally specified table to hold user data doesn't seem 
worth the effort, particularly when the legacy form of authentication 
doesn't handle database specific account information at all.

I think I understand the motivation for separating user name and user 
indentification, but I don't think it's a good idea.  It could be 
marginally useful, but it also be a source of endless confusion over 
which attributes, name or identification, was used in which context.  
For simplicity, which has virtual, let's stick with a single identifier 
for a database user.  That said, there is merit to record on user 
information like full name, fax number, and mother's maiden name.  Not 
all security models will want to track this stuff, but the 
fb_update_account_info mechanism should be able to accomodate it 
providing we can successfully manage the APB attribute space...

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

There will probably be more, but there won't be any fewer.

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.  I want to security plugin to have this information.  In 
general, only the last (first in order) address is reliable (subject to 
Nickolay's final approval, of course), but if other addresses can be 
identified as trustworthy, the chain has some value.  In any case, 
however, the other identification dpb parameters all provide lists of 
transmission agents by version, type, and product.  For what it's worth, 
Interbase supposed TCP, DECnet, Apollo ring, and transciently, 
Jim's-really-crappy-asynchronous-line-protocol.  Interbase servers were 
used as inter-network gateways all the time.

The database handle in fd_update_account_info is the target the 
database.  The security database is the business of a future plugin and, 
in general, inaccessible.

The fact that SHA (and MD5) may have collisions is irrelevent for 
password hashing.  The question is not whether collisions are possible, 
but whether you can compute a "collision" given a hash.

Alex has proposed an spb parameter to specify security database for 
gsec.  This is a very bad idea.  Security configuration data should 
reside solely in a write protected file.  Moving this stuff to a utility 
compounds mistakes made in the past.

Alex has also suggested that fb_update_account_info need not be thread 
safe.  This is incorrect.  The entire API must be thread safe.  All 
security plugins themselves must also be thread safe.  No component, 
whether Y-valve, remote interface, engine, or gateway, presumes to 
manage threading for any other component.  Every component is 
responsible for it's own thread safety.

-- 

Jim Starkey
Netfrastructure, Inc.
978 526-1376