RE: [Firebird-devel] User semantics vs authentication (was: crypt plugins)

[Thomas S. <ts...@ib...>]

Hi Dmitry,

> > My lack of experience with other systems means that I really
> > have no idea exactly how FB databases should implement support
> > for storing user identifiers, but I begin to suspect that some
> > sort of translation table may be required.  Something that
> > cross-references the plug-in defined user identifier to a
> > consistent FB format identifier.  There would then need to be
> > an API that took a give FB user-id, translated it to a plugin
> > user-id and then did an appropriate plugin call to discover
> > the actual user logon name.  This could make it interesting
> > getting the list of users.
> >
> > Anyone else have any thoughts or experience on this?
> 
> My own vision is presented below.
> 
> User should become a database object, like tables, roles, etc. This will
> allow reliable grants, defaut user roles and some other improvements. As a
> database object, it's being described by a standard SQL identifier
> (currently CHAR(31) UNICODE_FSS) which may be any valid string or number.
> 
> Authentication is a completely different beast which is external to a
> database (although may interact with a database via Jim's engine callbacks,
> including storage of password information inside a database). Authentication
> is implemented via PAM, with some standard (legacy security.fdb, OS level,
> EUA, etc) plugins provided in the kit. Each auth mechanism (plugin) has a
> unique identifier/name (?) and a number of auth parameters (id, login,
> password, biometrical data or whatever else) identifying a given auth
> account.
> 
> Each user is mapped to an external auth account. I'd propose something like
> 'CREATE USER <name> IDENTIFIED BY <auth_account_id>', but this is just me.
> For example, the current authentication may be described as IDENTIFIED BY
> 'login=<user>, password=<pwd>'. The used auth method may be stored in
> RDB$DATABASE, or provided in DPB, or specified in the IDENTIFIED BY stuff
> and hence stored in the users table... but I feel this is a completely
> different question to discuss.
> 
> The pros of the aforementioned idea:
> 
> 1) database user names and authentication ids are separated
> 2) users are stored inside the database, allowing some extra benefits
> 3) CREATE/ALTER/DROP USER are usual DDL commands always executed against the
> attached database
> 4) it's easy to switch from auth method to another without changing database
> users (or even allow different auth methods for different database users,
> although I'm nor sure this is good idea)
> 
> P.S. This is not a proposal, but a call for some brainstorming.

Storing the user names in the database is an excellent idea
if using the internal Firebird authentication, like it is
now, but with the difference, that the user isn't server-wide,
but database bound.

If I understand the plugin idea correctly, there could be a LDAP,
Kerberos, ... plugin, right?

With these external authentication mechanism used, would it be
still necessary to have the user created in the database? You
know, you would have to maintain the user again in different
places.

Or, would it be possible to define that a database user is
able to authenticate via LDAP or Kerberos or both?

Just my 2 cents.

Regards,
Thomas
PS: Great to see that there is work in that area in progress!!!