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.

[Francois Orsini]

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.

--francois

On 10/27/05, Satheesh Bandaram <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] > 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.