[
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)
- The notion of users defined at the system level is NOT just for Derby's
built-in authentication scheme - it is there so that we can better link and
integrate users from an outside realm than Derby's one - Sysusers would be a
great start and I would hope to use VTI internally to materialize (known) users
for a particular instance of Derby whether the built-in authentication scheme
is used or not..and I agree that Derby should not care as far as how the user
has been authenticated.
- Most database systems out there have DDL to define users managed by the
RDBMS, we don't have this at the moment - some are using a syntax such as:
- Grant Connet to username Identified by xyz;
or
- Create User username Identified by xyz;
as well as DDL for altering users.
- Introduce a rea and internal notion of a User object (descriptor) in Derby -
there is none today
Now, this could be done as part of this charter or not (separate JIRA) but
there would be dependencies at least how a user is instantiated internally (see
my last point) and the grant/revoke implementation at the user descriptor level.
> 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.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-464
> URL: http://issues.apache.org/jira/browse/DERBY-464
> Project: Derby
> Type: New Feature
> Components: SQL
> Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0
> Environment: generic
> Reporter: Satheesh Bandaram
> Assignee: Satheesh Bandaram
> Attachments: grant.html
>
> Derby currently provides a very simple permissions scheme, which is quite
> suitable for an embedded database system. End users of embedded Derby do not
> see Derby directly; they talk to a application that embeds Derby. So Derby
> left most of the access control work to the application. Under this scheme,
> Derby limits access on a per database or per system basis. A user can be
> granted full, read-only, or no access.
> This is less suitable in a general purpose SQL server. When end users or
> diverse applications can issue SQL commands directly against the database,
> Derby must provide more precise mechanisms to limit who can do what with the
> database.
> I propose to enhance Derby by implementing a subset of grant/revoke
> capabilities as specified by the SQL standard. I envision this work to
> involve the following tasks, at least:
> 1) Develop a specification of what capabilities I would like to add to Derby.
> 2) Provide a high level implementation scheme.
> 3) Pursue a staged development plan, with support for DDL added to Derby
> first.
> 4) Add support for runtime checking of these privileges.
> 5) Address migration and upgrade issues from previous releases and from old
> scheme to newer database.
> Since I think this is a large task, I would like to invite any interested
> people to work with me on this large and important enhancement to Derby.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
