db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3282) Add a mechanism for managing users in Derby
Date Thu, 20 Dec 2007 18:10:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553739
] 

Rick Hillegas commented on DERBY-3282:
--------------------------------------

Thanks for continuing the conversation about this topic, Øystein. Yes indeed, let's step
further back!

I agree that the definition of a Derby system is not what you might want. In practical terms
it is something like this: the set of Derby resources managed by a single VM relying on a
single set of system properties and a single master property file. It is not a set of Derby
databases, which might be what you want. Multiple Derby systems could run on a single machine
and, in the worst case, a given database could drift back and forth between two systems, depending
on which system touches it first after a reboot.

I understand the appeal of moving databases from one location to another, maybe even between
Derby systems. I think that this is particularly appealing for single-user, shrink-wrapped
applications. However, there are already limitations on this useful feature. For instance,
important aspects of a database's behavior may be governed by the master property file and
this does not live in the database's directory. In addition, a database is sensitive to the
version of Derby which created it. You can't move a 10.3 database into a Derby system which
is running 10.2. In order to move databases safely, you may also have to move some of the
"system" context.

Unfortunately, some authentication is already part of this "system" context. That is because
you need system-wide credentials in order to create databases and bring down the "system".
It seems awkward to me that you technically need one set of credentials in order to perform
these system tasks and another set of credentials in order to perform work in a database.
In practice, I seriously doubt that there are many (or even any) Derby applications which
use different credentials for system-wide vs. database-specific tasks. Good evidence for this
is provided I think by the fact that no production user has tripped across DERBY-3271 yet.

In fact, the system-wide credentials which you use to create a database MUST BE the very same
database-specific credentials which you use to do work in the database, at least initially.
This is because database creation actually involves two authentication passes. In the first
pass, you authenticate at the system level in order to create the system tables on disk. In
the second pass, you then authenticate (using the same credentials) at the database level
in order to get a connection to the newly created database. I don't believe that this coupling
of the two credential schemes is documented anywhere. It is an unwritten assumption about
the way that Derby authentication behaves.

I think it would be confusing and awkward to require customers to operate two different mechanisms
for administering users: one mechanism for administering users at the system level and another
mechanism for administering users at the database level.

For the record, I don't have any quarrel with the syntax described in DERBY-866. I do have
reservations about the database-specific scope of the syntax and about the requirement that
system-wide credentials be stored in the master property file.

> Add a mechanism for managing users in Derby
> -------------------------------------------
>
>                 Key: DERBY-3282
>                 URL: https://issues.apache.org/jira/browse/DERBY-3282
>             Project: Derby
>          Issue Type: Improvement
>          Components: Security
>            Reporter: Rick Hillegas
>
> Currently, managing users in Derby is awkward. The BUILTIN mechanism seems appropriate
for testing purposes, but has problems in a production setting. DERBY-866 describes part of
a new mechanism for managing users. DERBY-866 may be part of the right solution--or it may
not be. I think it would be worthwhile to step back from this issue and first describe at
a high level what the customer experience should be.  By introducing a  new mechanism, we
have the opportunity to think through the complete experience of user management. Here are
my initial thoughts:
> 1) This mechanism is mutually exclusive with the currently supported settings of the
derby.authentication.provider property.
> 2) There should be a super user who has the power to create, view, and drop users, including
database owners. The design should let this super user delegate these powers to other users.
> 3) In the new mechanism it is sufficient that user credentials are system-wide.
> 4) Database owners should nevertheless have the power to state which usernames can connect
to their databases. DBOs should also have the power to state who can shut down their databases.
This mechanism should be extensible to managing other database-specific powers which fall
outside the SQL spec. The design should let the DBO delegate these powers to other users.
> 5) Users should be able to change their own credentials whenever they want.
> 6) No password needed for this mechanism should be stored in plaintext anywhere on the
system.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message