db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-866) Derby User Management Enhancements
Date Thu, 01 Dec 2011 19:42:41 GMT

     [ https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Rick Hillegas updated DERBY-866:

    Attachment: dummyCredentials.properties

Here is a proposal for how NATIVE user management can handle system-wide users. That is, this
proposal handles authenticating orderly engine shutdown, database creation/restoration, and
other situations where there is no database in focus.

1) By default, NATIVE authentication successfully authenticates all user/password pairs in
system-wide situations. That is, there are no authentication checks preventing orderly engine
shutdown and database creation/restoration. In this default mode, Derby is vulnerable to denial-of-service
and resource-hogging exploits by anyone who can craft their own connection URLs.

2) We can introduce a new Derby property: derby.authentication.native.credentialsDB. This
property can be pointed at a distinguished Derby database. When this property is set, the
NATIVE credentials in the distinguished database are used for all authentication. That is,
credentials in the distinguished database work for system-wide authentication as well as for
ordinary connections to Derby databases. A typical use-case would be a networked Derby application
which uses a single database; in this use-case, that database would be set to be the distinguished
credentials database.

3) Note that what has been proposed so far merely puts an authentication hurdle in front of
denial-of-service and resource-hogging exploits. Any legal user could still shutdown the engine
and create unlimited numbers of databases. More protection against these attacks would be
provided by completing the system privileges work described by DERBY-2109.

A variation on this proposal would be:

2') The distinguished credentials database is only used for system-wide situations. When connecting
to an existing Derby database, the NATIVE credentials in that database are used. I think this
is a more difficult proposal because it could result in a single identity having to maintain
two sets of credentials: a system-wide set and a database-specific set. Note, however, that
there is no distinction between (2) and (2') for the typical use-case cited above, in which
a single database serves both as the distinguished credentials database as well as the application
data store.

For extra credit, we might want to make it easy to support the following scenario:

A) An application could supply a custom authenticator which relies on NATIVE authentication
when authenticating connections to existing databases but which validates system-wide users
via LDAP or local OS accounts. I am not sure it is worth spending extra effort to make this
scenario easy to support. That is because this usage suffers from the same problem as (2'):
a single identity would have to maintain multiple sets of credentials.


More on this problem of multiple credentials for a single identity:

It is clear that Derby authentication was designed to make it possible for an identity to
have multiple sets of credentials. This feature can be exploited currently by both BUILTIN
and application-supplied authentication schemes. However, it does not seem to me that the
feature is completely baked. In particular, at database creation time there is no way to tease
apart which set of credentials you intend. This forces you to keep both sets in sync. That
is because database creation and restoration entail 2 separate credentials checks: an initial
check using system-wide credentials followed by a connection attempt using database-specific

If you want to further investigate this double authentication problem, try out the attached
DummyAuthenticator and its dummyCredentials.properties file. Boot ij with the following command
line and try to create a database:

java \
  -Dderby.connection.requireAuthentication=true  \
  -Dderby.authentication.provider=DummyAuthenticator \
  -Dderby.database.sqlAuthorization=true \

> Derby User Management Enhancements
> ----------------------------------
>                 Key: DERBY-866
>                 URL: https://issues.apache.org/jira/browse/DERBY-866
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions:
>            Reporter: Francois Orsini
>         Attachments: Derby_User_Enhancement.html, Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java,
UserManagement.html, dummyCredentials.properties
> Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec attached
to the JIRA).
> Abstract:
> This feature aims at improving the way BUILT-IN users are managed in Derby by providing
a more intuitive and familiar DDL interface. Currently (in, Built-In users can be
defined at the system and/or database level. Users created at the system level can be defined
via JVM or/and Derby system properties in the derby.properties file. Built-in users created
at the database level are defined via a call to a Derby system procedure (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY)
which sets a database property.
> Defining a user at the system level is very convenient and practical during the development
phase (EOD) of an application - However, the user's password is not encrypted and consequently
appears in clear in the derby.properties file. Hence, for an application going into production,
whether it is embedded or not, it is preferable to create users at the database level where
the password is encrypted.
> There is no real ANSI SQL standard for managing users in SQL but by providing a more
intuitive and known interface, it will ease Built-In User management at the database level
as well as Derby's adoption.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message