In some systems, a schema is created per
users (implicit) and a schema cannot be created without an "owning"
user.
In other systems, schemas can be created
independent of users, but authorization descriptors can be associated with
schema descriptors.
This raises the question of how much, if at
all, we need to refince the current scheme of things regarding HSQLDB
authentication and authorization?
Will we need roles?
Will we need a cross-Database instance
Authentication/Authorization framework?
In general these facilities are intended
for better application level compatibility with other RDMS engines
and the latest SQL standards. However, they should not change the
single-database paradigm. Introducing roles is a good idea regardless of
anything else. A cross-database (persistent) framework would
complicate things and can be avoided at this stage.
2.) What are we willing / do we need to
specify concerning the relationship between authorization
descriptors and catalog descriptors?
This is a larger and more "intrusive" issue
than schema support, simply because the current HSQLDB
Authentication/Authorization framework is based completely upon th notion
of Database instance scoped users (and roles, the only one being ADMIN,
currently)
The issue here is that there needs to be a
standard for what constitutes Authentication/Authorization in an SQL
environment that allows the simultaneous existence of several otherwise
isolated database (let's call them catalog) instances.
What we can implement now is analogous to
user/resource authentication/authorization in an ad-hoc windows workgroup
which many are familiar with. In such a workgroup there is no central
authentication/authorization server. For seamless access to resources on
other machines, the user must exist on each machine with the same
password and certain access writes.
So if a database user has been created on
three different database, with certain privileges that are either granted
directly or by role, then a logon to one of the database allows
access to the others. This is in the context of a server that serves a
predefined set of databases.
As Fred and I have dicussed several times,
there is a need for a session language that extend in scope above that of
any individual database session.
The session language is needed for
something else, i.e. management of database in the server, e.g. adding a
new database, taking a database offline for maintenance, etc. It is a
separate issue. This level of managment needs only the degree of
metadata persistence that we already have in a server instance: a list of
databases and their aliases for a server.
There is also a need, then, for a
Session context to carry about, among other things, the union of the
Authentication/Authorization tokens successfully obtained against each
catalog opened in session scope.
This can be done ad-hoc via cross-database
system queries. Otherwise changes in grants in another
database context will not be reflected in the current
session.
I have done some work in the HSQLDB MX
package to allow delegation of Authentication/Authorization to a
java.security (whole JVM) style facility, which can easily be adapted to
the Java security policy framework, if desired. It is also not
difficult to implement a cross-JVM ACL-based security manager, for JDK
1.1.
But, still, the devil's in the
details.
The main limiter here is that what
ever we specifiy regarding the behaviour and details of catalog support,
it should apply _only_ to the in-process perspective. There is a
perfectly acceptable standard that we can implement regarding the wider
scope (i.e. out-of-process federation/clustering), as described in the SQL
standards under the heading of SQL MED (management of external
data). I belive that Fred/Bela and crew still have some hopes to see
this part implemented as a standard but optional extention item, as
exemplified by the existence of the HSQLDB/R demonstration
prototype.
This can wait until the infrastructure has
been implemented. We are still going to implement
federation/clustering.
Finally, the scopes of the
parser/_expression_/commandinterpreter facilities need to be expanded to be
able to handle cross catalog concerns.
Certainly. This is needed in the first
instance.
Obviously, there are deeper, more troublesome
issues that remain unresolved and that we probably do not want to tackle
right away, such as cross-catalog referential integrity, cross-catalog
views, cross-catalog routine references, etc., mostly because the current
state of affairs does not guarantee that a referenced catalog will remain
available for the lifetime of the objects that reference it.
Such issues depend on what we allow. For
instance, we do not have to allow cross-database referential integrity
constraints. Routine references should resolve in the context
of the database that calls the routine or the one that contains the
referenced table on which the routine is called depending on the calling
context.
We should not have to guarantee that a
referenced catalog remains open, so we can plan accordingly.
