However, even as of today, databases can be dependent on users defined at the system level if you have 'derby.database.propertiesOnly' set to false which is the default I believe ;)
What I meant to say is: (and this was in the context of Grant&Revoke access to database(s) when users are defined at the system level in my case which I think we'll be the most popular choice - 80/20 rule)
It's ok to have a user being defined as a legitimate user of a database (sysusers catalog in the database for instance - never meant to remove a notion like that since we allow something similar today) - but on the other hands, one should not have to define users at the database level if they don't want to. Today we can have a user password being encrypted at the database level but not at the system one - hence the motivation for improving this at the system level in the case of Derby's built-in authentication (password-based) - we should not require to have to define users' credentials in every database they can access because we think a database should be independent of the system level (one) - it is great of course but there could be user management useability issues having to manage a user across several databases if one does not plug into a directory service (i.e. LDAP)...User definitions and therefore credentials at the System level are too exposed right now and we know why - user definition at the database level is more secure than at the system level and I believe this should be fixed/addressed (am not a big fan of exposed system properties either and especially when passwords are involved) but this is the path we had decided as you said...
I'm just guessing and I may be wrong that most DBA's will either want to define users at the system level _or_ have Derby authenticate against their directory service (users' credentials managed outside then).
So yes, we could have a Sysusers (virtual or not) table at the database and system level to define user access for the database or system-wide, as well as providing a more secure storage for encrypted passwords (and especially for the users defined at the system level). This would provide a unified way of storing user credentials for the built-in scheme at least as well as looking at current defined users (i.e. common sysusers interface)
--francois
On 10/26/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote:
Francois Orsini (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-464?page=comments#action_12356032 ]
>
> Francois Orsini commented on DERBY-464:
> ---------------------------------------
>
> The way I implememted users in Cloudscape originally was done in a "Cloudscape running Embedded" mindset rather than anything else - in a similar way we what ww have done for permissions via properties - defining users is one thing, authenticating them via various schemes in another - For instance today, users defined at the System level, not database one, do not have their password encrypted for the built-in authentication scheme. I agree that users can be defined outside of Derby but we can't assume all organizations have an LDAP server out there - in fact, a lot if not most of them still don't have one.
>
> What I have in mind for Derby defined users is the following:
>
> - Users should be defined at the System level and added to databases as required (Grant access to a database)
That, to my mind would be a bad step. Currently Derby databases are
independent of any system, they are self contained. Thus they can be
copied anywhere and continue to work. Adding a dependency on a system
database just seems wrong.
I've often thought that one mistake made in the early days was to have
the concept of a system, the single derby.properties, derby.log file, or
reading system properties.
Dan.
