Leyne, Sean wrote:

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

Sean, what does the security plugin that emulates the current semantics
do? Do it replicate FB$USERS from the security database? Does it try
to intercept references to FB$USERS and redirect to the security
database? Replication, of course, is impossible for a readonly
database. The redirection, on the other hand, would be massively
complicated to implement, requiring a very "rich" security plugin API.

What about users authenticated with PAM, LDAP, or NT Domain? Do they
get replicated? On first reference? Again, what about readonly databases?

If we're going to support a minimal FB$USERS, we have to solve these
problems. I, for one, don't have a decent solution that fits all cases.

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

Uh, not really.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376



[Non-text portions of this message have been removed]