db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5522) Document the NATIVE authentication scheme.
Date Mon, 19 Mar 2012 16:12:38 GMT

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

Rick Hillegas commented on DERBY-5522:
--------------------------------------

Thanks for this first tranche of changes, Kim. I can see that this is a big effort indeed.
On the whole, these changes look great to me.

I now understand why you asked so many questions about the sample programs. I see that the
programs originated in the docs examples. Now that I see that the programs are going to be
exposed, I think that we should overhaul them. They don't showcase how easy Derby is to use--and
how much easier authentication has become with the new NATIVE mechanism. If you like, I would
be happy to rewrite these examples to try to showcase how simple Derby security is becoming.
We just need to agree on what points the examples should punch up.


cdevcsecure36127:

I stumbled over the first paragraph. I would be tempted to reword it slightly:

"If you use NATIVE authentication, then you do not need to set the derby.connection.requireAuthentication
property. When creating a database with NATIVE authentication, simply specify a username and
password--that user becomes the database owner."


cdevcsecure36595:

I would recommend some changes to the pre-existing wording. In general, I don't think that
the term "user authorizations" conveys any more meaning than the simpler term "authorizations".
On the contrary, I think it is easy to be confused by the term "user authorizations" and to
suppose that it is yet another kind of authorization scheme in addition to "connection authorizations"
and "SQL authorizations". There are only 2 kinds of authorizations and I find that the qualifiers
"coarse-grained" and "fine-grained" help me tease them apart.

o Paragraph 2 under "User authorizations":

  "Connection authorization specifies the access" -> "Connection authorization specifies
the coarse-grained access"

  "SQL authorization controls the permissions" -> "SQL authorization controls the fine-grained
permissions"

o Paragraph 4 under "User authorizations": Coarse-grained connection authorization and fine-grained
SQL authorization are independent of one another. You can enable both of them if you want
to. NATIVE authentication does not affect this independence. If you turn on NATIVE authentication,
then you can also turn on coarse-grained connection authorization. I have verified this. Here
is an attempt to reword this paragraph:

"Attention: If you use NATIVE authentication, then fine-grained SQL authorization is automatically
enabled, and by default, all users enjoy full coarse-grained access to the database. In this
situation, fine-grained SQL authorization can't be turned off. However, you can still adjust
coarse-grained access to the database."


o Paragraph 3 under "User authorization properties": The html output is missing the blank
line which I think should introduce the new paragraph that begins with the sentence "The following
properties affect authorization:"


o Paragraph 4 under "User authorization properties": This paragraph really confuses me. I
think that it is supposed to be talking about coarse-grained connection authorizations, but
it uses the ambiguous term "user authorizations". I recommend rewording it:

"If you do not specify the coarse-grained connection authorizations for a specific user ID,
then that user ID inherits the database's default coarse-grained connection authorization."


o Bullet 3 under "How user authorization properties work together": The two authorization
mechanisms do not override one another. They supplement or refine one another. A user's authorizations
end up being the intersection of her coarse-grained and fine-grained permissions. I would
reword the first sentence of this bullet as follows:

"The coarse-grained access mode specified by the derby.database.defaultConnectionMode property
supplements the permissions that  re granted by the owner of a database object."


cdevcsecure42374:

One specific comment, then a general comment about the pre-existing wording.

o Bullet 1: I would drop the sentence about robustness. I don't think we want to imply that
LDAP or user-written mechanisms are less safe.

The pre-existing wording seems a bit confused to me. It creates the impression that authentication
controls access to the Derby engine and authorization controls access to individual databases.
That's not how it works. Here's how I see it:

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.


cdevcsecure51876:

o Bullet 2: I was confused by multiple references to authorization in this sentence. I would
reword it to something like this:

"These examples show how to use fine-grained SQL authorization in conjunction with Derby's
NATIVE user authentication."


cdevcsecurenativeauth:

o Paragraph 1 under "Using NATIVE authentication": Again, I would drop the claim that NATIVE
authentication is safer than LDAP. Maybe something like this:

"Derby's simplest authentication mechanism is NATIVE authentication."

o Last paragraph  under "Using NATIVE authentication": I would clarify when passwords are
hashed. I would reword the first sentence of this paragraph:

"Use the derby.authentication.builtin.algorithm property to change how passwords are encrypted
when they are stored in SYS.SYSUSERS."

o Last bullet under "Managing users and passwords": I would punch up the purpose of this procedure:

  "To change a password" -> "To change her own password"


rdevcsecuresqlauthclientex:

o Paragraph 3 under "User authentication and SQL authorization client example": I was confused
by the last sentence of this paragraph. I couldn't figure out what "format" referred to.

See my introductory comment about these examples: I see that these programs are pre-existing
code, which you have reworked to use NATIVE authentication. I think it would be great if the
examples could be simplified to highlight how easy it is to set up NATIVE authentication.
In particular, because BUILTIN isn't being used anymore, there is no need to call syscs_set_database_property()
at all. If the following property is set on the server...

 -Dderby.authentication.provider=NATIVE:nativeAuthClientDB:LOCAL

...then the following work will happen automagically:

1) derby.authentication.provider=NATIVE::LOCAL will be set in the database.

2) The SYSADM credentials will be loaded automatically.

3) And there is no need to set databaseOnlyProperties. The database has been secured by NATIVE::LOCAL
authentication so there is no way to subvert authentication now.

I also think that we should remove the code which sets coarse-grained connection authorizations.
I believe that this material should have been removed when we introduced fine-grained SQL
authorizations in 10.2.

Please be patient as we improve these examples. I think that this may take a couple iterations.
As I said earlier, if you like, I can create a simpler example from scratch once we agree
on what the example should show.


rdevcsecuresqlauthembeddedex:

Similar comments.


rdevcsecuresqlauthsyspropex:

I'm tempted to get rid of this page and just roll its material into the previous examples.
Can you think of a reason why we need this extra page?


tdevcsecure81850:

o Item 4: Again, I think that we only need to recommend SQL authorization. I would reword
the first sentence as follows:

"To prevent unauthorized users from accessing databases once they are booted, turn on user
authentication and SQL authorization for the database."

o Item 5: I think that this page is about how to configure security in a production environment.
I don't think that we should mention BUILTIN authentication at all since it is not secure.
I would just reduce this item to the following. If we remove the bit about BUILTIN authentcation,
then there's nothing left to this item except the advice to turn on SSL/TLS. But that doesn't
make sense for an embedded scenario. So I would reduce this item to the following and move
it to the next page (which deals with configuring network security):

"It is also strongly recommended that production systems protect network connections with
SSL/TLS."


tdevcsecure82556:

o Item 3: Again, let's not mention BUILTIN authentication. Strike the last two sentences of
this item.

o Item 4: This text assumes that you are using coarse-grained connection authorization rather
than fine-grained SQL authorization. Again, I think that we should stop recommending the old-style,
Derby-specific coarse-grained mechanism. Instead, we should recommend that people use portable
SQL Standard features wherever possible. I would simplify this item as follows:

"Configure SQL authorization for your databases."

                
> Document the NATIVE authentication scheme.
> ------------------------------------------
>
>                 Key: DERBY-5522
>                 URL: https://issues.apache.org/jira/browse/DERBY-5522
>             Project: Derby
>          Issue Type: Improvement
>          Components: Documentation
>    Affects Versions: 10.9.0.0
>            Reporter: Rick Hillegas
>            Assignee: Kim Haase
>         Attachments: CreateNativeUsers.java, CreateNativeUsers.java, DERBY-5522-devguide.diff,
DERBY-5522-devguide.stat, DERBY-5522-devguide.zip, NativeAuthExampleClient1.java, NativeAuthExampleClient2.java,
NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java,
NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java, NativeAuthExampleEmbedded.java,
UseNativeUsers.java, UseNativeUsers.java
>
>
> We should document NATIVE authentication after we have implemented the changes described
on DERBY-866. The documentation changes are described by the functional spec UserManagement.html
attached to that issue.

--
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