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] Commented: (DERBY-464) Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner level of privileges than currently provided by Derby that is especially useful in network configurations.
Date Fri, 28 Oct 2005 01:25:48 GMT
Derby's Built-in authentication can be used in a client-server mode today
along with DRDA's secure transport mechanisms of users' credential across
the wire. Originally, we had no cloudscape network driver besides 3rd party
ones which were NOT providing secure transport of user credentials across
the wire besides using SSL (which encrypts everything not just credentials -
overkill if you don't need it) - I don't see why we could not improve the
way user & passwords are stored at the system level to be as secure as the
ones defined at the database level. This is internal afterall - then, I
would like to see a unified way of defining users at the database and system
level when using built-in authentication - a simple 'CREATE USER' command
for instance (and am just taking a quick example) would do it and improve
useability at the same time - implementation details (storage) are internal
as it is done at the database level...I believe that Derby will be used more
and more in a client-server mode, along with built-in authentication way of
storing credentials (SHA-1 single-hashed) which is fairly secure already (at
the database level) - yes a few bits could be improved but the storage of
credentials is actually pretty good at the database level.

It does not make sense anymore to have to have 2 ways to define users for a
particular authentication scheme which is the built-in database system one.

This is exactly in-line as far as why we would implement grant/revoke now
since we didn't think we needed it when we implemented the other and simpler
scheme via properties back then as we were thinking embedded (which lead us
to piggy-back on using java 'properties' to define ACLs as we did for users)

Authorization is different than authentication, hence I agree with the
second part of your statement.

I will post a proposal once am done and the community can comment on it.


On 10/27/05, Satheesh Bandaram <satheesh@sourcery.org> wrote:
> Why exactly would we want to strengthen builtin-authentication scheme when
> all of us agreed it was for simple embedded application use? I am not sure
> how useful access control is for embedded usages.
> But I will hold off on any more questions and wait for your proposal.
> Satheesh
> Francois Orsini wrote:
> I'm all for having a homogeneous and unified way to manage (create, drop,
> alter, etc) users in Derby and specifically for the built-in authentication
> scheme which is what I was referring to. Today we simply don't have that.
> More to follow as am starting to feel itchy ;)
> --francois
> On 10/26/05, Daniel John Debrunner <djd@debrunners.com> wrote:
> >
> > Francois Orsini wrote:
> >
> > > Agreed since we always made it clear that users could be defined at
> > the
> > > system and/or database level ;)
> > >
> > > 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)
> >
> > Yep, flexibility is good. As long as we continue to support
> > self-contained databases. A system database would be a significant new
> > feature.
> >
> > Of course, I'm unclear on exactly what you are proposing, is it a new
> > authentication scheme or something else? I eagerly await the functional
> > spec/proposal. :-)
> >
> > Dan.
> >
> >
> >

View raw message