[
https://issues.apache.org/jira/browse/DERBY-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas closed DERBY-3282.
--------------------------------
Resolution: Duplicate
Closing this issue. Marking it as a duplicate of DERBY-866. I think that the
problem raised by this issue is largely addressed by NATIVE authentication.
> 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: Services
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
