db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kim Haase (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5636) Improve the overview of Derby's security mechanisms
Date Tue, 20 Mar 2012 13:57:39 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13233411#comment-13233411
] 

Kim Haase commented on DERBY-5636:
----------------------------------

The "Derby and security" main topic should clarify the authentication/authorization distinction
as described by Rick under DERBY-5522, or should at a minimum point to other topics that make
this clear:

1) Authentication determines whether you are a legal user. It establishes your identity.

2) Authorization determines what operations can be performed by you, that is, by your Derby
identity.

So far, so good. Those are just generic definitions of authentication and authorization which
hold true for lots of software, not just Derby. Now for the tricky bit, which is specific
to Derby:

Derby understands two kinds of identity:

A) System-wide identity. Currently, any legal system-wide identity enjoys authorization to
perform the following operations:

  i) Create databases.

  ii) Restore databases.

  iii) Shutdown the Derby engine.

B) Database-specific identity. If you are a legal identity in a specific-database, then you
may enjoy the following rights:

  i) You can connect to that database--provided that   coarse-grained connection authorization
has not been set to noAccess.

  ii) You can shutdown that database, encrypt it, and upgrade it--provided that   you are
the database owner.

  iii) You can create your own SQL objects and write data to your own   tables--provided that
your coarse-grained connection authorization   has not be set to readOnlyAccess.

  iv) You can access other SQL objects--provided that the   owners have granted you fine-grained
SQL access to those objects and   provided you have not been limited by coarse-grained readOnlyAccess.

                
> Improve the overview of Derby's security mechanisms
> ---------------------------------------------------
>
>                 Key: DERBY-5636
>                 URL: https://issues.apache.org/jira/browse/DERBY-5636
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation
>    Affects Versions: 10.9.0.0
>            Reporter: Rick Hillegas
>            Assignee: Kim Haase
>
> The documentation on Derby's security mechanisms is scattered across several manuals.
This makes it hard for developers to figure out which security mechanisms are relevant for
a given application. Here are 3 places where security documentation appears:
> 1) In the Developer's Guide section titled "Derby and security"
> 2) In the Admin Guide section titled "Derby Network Server advanced topics"
> 3) In the Reference Manual section titled "Derby properties" as well as the syntax sections
on GRANT, REVOKE, CREATE/DROP ROLE, and CREATE FUNCTION/PROCEDURE.
> It would be good to add a section which points the developer at all of this material.
It might be sufficient to rewrite the top level "Derby and security" page of the Developer's
Guide. The following white paper may help organize our thoughts about this: http://www.oracle.com/technetwork/java/javadb/securitywhitepaper10-159253.pdf

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message