[jira] Commented: (DERBY-3282) Add a mechanism for managing users in Derby

["Øystein Grøvlen (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553709 ] 

Øystein Grøvlen commented on DERBY-3282:
----------------------------------------

I find it a bit difficult to relate to the concept system-wide users
since I feel it is not very well defined what a Derby system actually
is.  Hence, I think we first need to step back even further and
discuss the need for system-wide administration, in general.  Why do
we want system-wide administration? How will an administrator define a
system and add databases to a system?  What kind of properties should
the databases of a system share?

With the current flexibility where you are able to just copy a
database to another location and keep on using it as before, it
becomes very difficult to maintain information at system level.  It
also seems like it confuses many that users can be defined at two
levels, system and database.  I think the most important goal is to
make Derby easy to get started with for new users.  For that purpose,
and for the purpose of single database administration, users at
database level should suffice.  However, the problem is that the
current administration of built-in database users is awkward and
different from what people are used to from other database systems.  I
think DERBY-866 shows how this situation can be improved.

Then you have the minority of Derby users that administrates several
databases and find it tedious (and maybe error-prone) to repeat the
same administrative operations on all databases.  They would probably
like to have some tool that ease the administration of all databases
of the system.  A tool that let them create databases, add users at
system level etc.  It seems to me that the simplest would be to
require that the only way to update information at system level is
through this tool.  To keep the current flexibility, if some of the
system information is to affect a database, this tool will have to
push the information into the database.  For example, when a user is
defined in this tool, the tool will create a built-in database level
user in all the databases for which this user is to be known.  

While such a tool would be good to have, I feel it is much less
important than to get a usable solution at database level. I also feel
that it is pretty independent of what we do with respect to DERBY-866.




> 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: Security
>            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.
-
You can reply to this email to add a comment to the issue online.