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

Rick Hillegas updated DERBY-866:
--------------------------------

    Attachment: UserManagement.html

Attaching version 7 of the functional spec. This version describes the new 
behavior which was just checked in. Changes are summarized in the version 7.0 
comment at the head of the spec:

"Introduced a new rule to simplify the conversion of legacy databases to NATIVE 
authentication and to make it harder to subvert a Credentials DB. The new rule 
is this: A database is a Credentials DB iff credentials have been stored in its 
SYS.SYSUSERS table.

o    Clarified that derby.authentication.provider is set to the value 
NATIVE::LOCAL by Derby itself and that this value is never explicitly set by an 
application.
o    Clarified that a legacy database becomes a Credentials DB when the DBO 
stores her credentials in SYS.SYSUSERS. Revised the example in the Database 
Creation section accordingly. Repeated this clarification in the section on 
Hard Upgrade.
o    Clarified that the DBO's credentials must be the very first credentials 
stored in a legacy database via the syscs_util.syscs_create_user procedure. 
Calling this procedure permanently marks a database as a Credentials DB.

In addition, clarified that when NATIVE authentication is enabled, Derby 
behaves as if derby.connection.requireAuthentication=true and 
derby.database.sqlAuthorization=true regardless of how those properties are set 
by any other means."
                
> 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, 
> UserManagement.html, UserManagement.html, UserManagement.html, 
> UserManagement.html, derby-866-01-aa-sysusers.diff, 
> derby-866-01-ab-sysusers.diff, derby-866-02-ag-createDropUser.diff, 
> derby-866-03-aa-resetModifyPassword.diff, 
> derby-866-03-ab-resetModifyPassword.diff, derby-866-04-aa-fixRolesTest.diff, 
> derby-866-05-aa-grantRevoke.diff, derby-866-06-aa-upgradeFrom10.1.diff, 
> derby-866-07-aa-removeSQLPassword.diff, derby-866-08-aa-passwordHasher.diff, 
> derby-866-08-ab-passwordHasher.diff, derby-866-08-ad-passwordHasher.diff, 
> derby-866-09-ad-nativeAuthenticationService.diff, 
> derby-866-09-ae-nativeAuthenticationServiceWithTests.diff, 
> derby-866-10-ac-propChanging.diff, derby-866-11-aa-upgradeTest.diff, 
> derby-866-12-ac-passwordExpiration.diff, 
> derby-866-13-ab-systemWideOperationTests.diff, 
> derby-866-14-ac-badNativeSpec.diff, 
> derby-866-15-ae-dbInJarFileOrOnClasspath.diff, 
> derby-866-16-aa-credDBViaSubprotocol.diff, 
> derby-866-17-aa-grantRevokeNative.diff, 
> derby-866-18-aa-encryptedCredentialsDB.diff, 
> derby-866-19-aa-replicationTest.diff, derby-866-20-aa-npeAndUserProbing.diff, 
> derby-866-20-ab-npeAndUserProbing.diff, 
> derby-866-21-aa-emptyCredentials.diff, derby-866-21-ab-emptyCredentials.diff, 
> derby-866-22-aa-dboFirst.diff, dummyCredentials.properties, releaseNote.html
>
>
> 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


Reply via email to