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-5522) Document the NATIVE authentication scheme.
Date Thu, 08 Mar 2012 17:55:57 GMT

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

Kim Haase commented on DERBY-5522:
----------------------------------

I'm putting the following exchange between me and Rick into the public record, since my questions
don't seem to have been *too* stupid:

On 3/7/12 7:00 AM, Kim Haase wrote:
> On 03/07/12 08:45 AM, Rick Hillegas wrote:
>> Hi Kim,
>>
>> Thanks for picking up this issue. Some comments inline...
>>
>> On 3/6/12 1:34 PM, Kim Haase wrote:
>>> Hi, Rick,
>>>
>>> I'm starting to work on documenting native authentication. (Or should
>>> I say NATIVE? I'm thinking of using NATIVE vs. BUILTIN rather than
>>> native vs. built-in -- would that make sense?)
>> I've been using NATIVE instead of native for the same reason: it's more
>> parallel to BUILTIN.
>
> Thanks, Rick. We've been calling it "built-in" except when referring explicitly to the
keyword, but my idea is to change that.

Sounds good.

>
>>>
>>> Where does native authentication fit into the hierarchy of recommended
>>> mechanisms? We've had this note inserted in various places --
>> NATIVE authentication is intended to be a production-quality replacement
>> for BUILTIN. The release note tells people how to upgrade from BUILTIN
>> to NATIVE. Companies should be able to rely on NATIVE authentication and
>> feel as secure as they do with LDAP.
>>>
>>> "Important: Derby's built-in authentication mechanism is suitable only
>>> for development and testing purposes. It is strongly recommended that
>>> production systems rely on an external directory service such as LDAP
>>> or a user-defined class for authentication. It is also strongly
>>> recommended that production systems protect network connections with
>>> SSL/TLS."
>>>
>>> I'm guessing that for production we would still recommend LDAP over
>>> the others? Would native be preferable to a user-defined class? How
>>> likely are people to grow their own? Native would certainly be easier
>>> to use. I notice that you recommend SSL/TLS with native, implying that
>>> it might be used in production? Or is SSL/TLS just a good idea anyway?
>> Here's how I see it:
>>
>> 1) NATIVE is the secure authentication mechanism which comes with Derby
>> and works out of the box. It's great for standalone applications.
>>
>> 2) LDAP is good for departmental applications where users can be
>> expected to have a company-wide identity. It simplifies identity
>> management for enterprises: a user just needs one set of credentials in
>> order to use many applications.
>>
>> 3) User-defined authentication provides a thin bridge to external
>> authentication mechanisms other than LDAP. It's for companies and
>> application suites which use something other than LDAP to define user
>> identity across their departments and products.
>>
>> 4) BUILTIN authentication is a testing tool intended for Derby
>> developers. It lets you declare a canned set of users for your tests.
>> It's unfortunate that it escaped from the laboratory into the wild. I
>> think that we should remove all mention of it from the user guides--but
>> we probably want to clear that with the community.
>
> I think we need to warn people ahead of time -- perhaps at 10.9 we can say that use of
BUILTIN is deprecated and will no longer be documented at the next release, and then remove
it at the 10.9 bugfix release.
That sounds prudent.
>
> Would you actually remove support for BUILTIN itself at some future release? Or leave
it in there for testing purposes?

I think we have to leave it in for backward compatibility reasons and because our own tests
rely on it. But it would be good to stop advertising it.

Thanks,
-Rick
>
>>
>> In listing authentication mechanisms, I would lead with the
>> functionality which comes with Derby (NATIVE) and then follow with the
>> plugins (LDAP and user-supplied).
>
> Thanks -- that's helpful.
>
>>
>> About SSL/TLS: it's a good way to protect credentials from being sniffed
>> in networked applications, regardless of the authentication mechanism.
>>>
>>> I'm guessing those user authentication/authorization examples Dag and
>>> I worked on for the Developer's Guide should probably be rewritten to
>>> use native authentication instead? Not providing examples of builtin
>>> authentication should discourage people from using it.
>> Yes please!
>
> OK!
>
> Kim
>
>>
>> Thanks,
>> -Rick
>>>
>>> Thanks for your thoughts!
>>>
>>> Kim

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