[
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
DummyAuthenticator.java
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 credentials.
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 \
org.apache.derby.tools.ij
> 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: 10.2.1.6
> 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
> 10.1.2.1), 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
