Jim,

{While digesting the overall details of the posting... allow me to offer
this comment}

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

One approach to get around the unsatisfying feeling could to consider
FB$Users as having the _minimum_ information required/expected to be
provided by all security approaches. Since the engine needs some basic
information from which security needs to 'hang'.

From there each plug-in would be expected to create custom tables to
store their specific information, i.e. FB$Users_PAM, FB$Users_LDAP,
FB$Users_NTDomain... Thus for any given database there would be at
least 2 FB$Users**** tables.

In that way, each plug-in would be able to define whatever structure
they require, while still providing the basic information needed by the
engine.

So, does this make you feel more satisfied?


Sean