db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: [jira] Created: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements
Date Thu, 26 Jan 2006 09:15:42 GMT
On 1/25/06, Satheesh Bandaram <satheesh@sourcery.org> wrote:
>  Thanks for your answers, Francois... Some more below...
> On 1/24/06, Satheesh Bandaram <satheesh@sourcery.org > wrote:
> >
> >
> > Why not sure LDAP or some other standard authentication models? It may be
> good to strengthen Derby authentication, but not necessarily by making Derby
> manage passwords.
>  Derby Built-In authentication is important - again, not everyone is using
> LDAP, especially with small departmental level type of databases as well as
> embedded / disconnected ones.
>  Having Derby manage passwords is not very convinient... Users have to
> manage their username/password to their machines and also a different system
> to databases that is not as secure nor has good tools. If you remember,
> Sybase had elaborate stored procedures to add users and to manage their
> passwords initially. I think (if my memory serves right), they removed
> support for all these later and instead tied up with operating system based
> users/passwords. Not sure if Java has a way to link up to a (commonly used)
> domain server or just to host user management or other mechanisms, but that
> would surely be better.

No - Sybase still has a built-in authentication mechanism called 'ASE'
(sp_addlogin mylogin, mypassword, @auth_mech = ASE) - they also
support different authentication mechanisms like Derby does. Sybase
can also map an LDAP user to a Sybase ASE user via sp_maplogin
(corresponding to the EXTERNAL attribute mentioned in the
JIRA)...Again, we already have a built-in authentication scheme as
many (if not most) other database systems out there - If people want
to map an external user (login) with a built-in one, we can provide
this as well via the EXTERNAL attribute - Some applications may also
require to ship a database with user credentials already pre-set for a
client application which itself could run disconnected.

>  No - this phase I proposal is to enhance the DDL support for managing
> Built-In Derby users in a database. We would still be using database
> properties to store the actual user/password combination as presently.
>  OK. That clarifies what you are proposing. Dan does have a point about how
> new DDL makes it much better than what is already there.

I think Dan's point is towards using derby procedures instead of
SQL-like DDL though

> >
> > Why not make SYSUSERS a system table now, instead of a VTI? Making it a
> system catalog has benifits like dictionary management.
>  Agreed - just a question of phasing something in different stages - Also,
> we would not have to do any upgrade changes with this first phase since it
> would still be going after database properties underneath. I agree that the
> upgrade issue would still have to be done if sysusers is added - at the same
> time, it is very likely that it will be required if additional user
> semantics are added (i.e. profiles, pwd expiration, roles (hence UID
> required instead of username) - so Yes, this is a valid point
>  More profile/password management changes to Derby? I am not sure if that
> adds much value, IMHO, since there are many other services that do this much
> better already and are more secure.

It is all about offering various choices to end-users, not everyone is
running an LDAP or PAM external authentication server - as far as
password expiration and account locking, most known database systems
out there offer this as part of their built-in user scheme...What you
mentioned here is on phase 2 btw.

Thanks for the additional comments Satheesh.

>  Satheesh
>  Thanks for all the comments.
> > Satheesh
> >
> >
> > Francois Orsini (JIRA) wrote:
> >
> > BUILT-IN Derby User Management (DDL) Enhancements
> > -------------------------------------------------
> >
> > Key: DERBY-866
> > URL:
> > http://issues.apache.org/jira/browse/DERBY-866
> > Project: Derby
> > Type: Improvement
> > Components: Security
> > Versions:
> >
> > Reporter: Francois Orsini
> > Fix For:
> > Attachments: Derby_User_Enhancement.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
> >, 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
> 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.
> >
> >
> >
> >

View raw message