[
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
