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

[Dmitry Y. <di...@us...>]

"Geoff Worboys" <ge...@te...> wrote:

> 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.


Dmitry