[
https://issues.apache.org/jira/browse/DERBY-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167489#comment-13167489
]
Rick Hillegas commented on DERBY-866:
-------------------------------------
Thanks for continuing to help me think about this issue, Mike and Bryan. I
believe that the scenarios you want to see should be possible to configure.
Some responses follow:
Mike asks: "Is it necessary to have a separate credentials database in a system
with multiple databases, or is that an option?" It is an option. The
credentials database could just be one of the databases already managed by the
application.
Bryan asks: "Would it help to have a configuration option for the NetworkServer
where it could be explicitly
pointed at a specific database and told 'use the credentials in THIS database
for overall server
authentication'?" Perhaps what you are asking for is a simple way to configure
the following behavior:
i) When connecting to an existing database, use the NATIVE credentials in that
database.
ii) When authenticating system-wide actions (server startup/shutdown,
create/restore database), use the credentials in a specially designated
credentials DB (which could be one of the existing databases or could be
another, separate database).
Bryan's use can be configured as follows:
1) Create empty application databases without authentication (but supply
credentials so that a dbo account is created).
2) In each of those databases, set derby.authentication.provider=NATIVE::
3) Bring down the installation.
4) Now reboot the installation, setting the following property on the command
line: derby.authentication.provider=NATIVE:networkServerCredentialsDB
5) Continue creating the schemas in your application databases.
If you can help me describe the scenarios which should be easiest to configure,
I can adjust the api to make this possible.
In any event, did I understand your scenario correctly, Bryan?
Thanks,
-Rick
> 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
> Assignee: Rick Hillegas
> Attachments: Derby_User_Enhancement.html,
> Derby_User_Enhancement_v1.1.html, DummyAuthenticator.java,
> UserManagement.html, UserManagement.html, UserManagement.html,
> derby-866-01-aa-sysusers.diff, derby-866-01-ab-sysusers.diff,
> 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
