[
https://issues.apache.org/jira/browse/NIFI-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15269068#comment-15269068
]
ASF GitHub Bot commented on NIFI-1614:
--------------------------------------
Github user alopresto commented on the pull request:
https://github.com/apache/nifi/pull/267#issuecomment-216594397
My recommendation would be a command line utility (could be a shell script
wrapping a JAR) which is invoked without arguments, provides a secure prompt
for entering a raw password, and returns the hashed password in _bcrypt_
format.
I think the Java code necessary to read from the XML configuration file,
accept a username and password entered in the UI form field, verify the
credentials are correct, and return a JWT authentication token should remain.
The administrative functionality of the utility (reading and writing the
XML file) does not seem necessary to me.
Again, I understand the desire for this from a proof-of-concept and
quick-deploy mindset, but I'll reiterate my feeling that this lightweight
option will become an accidental de facto default because it requires less
effort to deploy than LDAP, Kerberos, or client certificate authentication.
Currently, I believe those alternatives are all more robust and secure than
this approach:
- Each is a widely supported approach with many eyes on them, making
discovery of vulnerabilities more likely
- Each protects the knowledge of the end users' passwords from the
administrator, unlike this approach
- Each scales without the manual intervention of the administrator
(authorization still requires manual intervention)
I appreciate the effort to move away from anonymous access as the default
for the application. However, I believe there should be a balance here, as the
default is very clear that no authentication is performed. Administrators must
make an intentional effort to secure the instance with LDAP, Kerberos, or
client certificates, all of which I acknowledge have a higher cost of entry
than simple username/password authentication from a file store. My fear is that
as this method is the lowest cost, it will be explained (incompletely) on a
random blog article, become the quickest route for admins to get it running
without fully reading the documentation or knowing its limitations, and then be
deployed to a production environment.
I understand these concerns are mostly intuitive and not examples I can
point to with empirical evidence.
> Simple Username/Password Authentication
> ---------------------------------------
>
> Key: NIFI-1614
> URL: https://issues.apache.org/jira/browse/NIFI-1614
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Reporter: James Wing
> Priority: Minor
>
> NiFi should include a simple option for username/password authentication
> backed by a local file store. NiFi's existing certificate and LDAP
> authentication schemes are very secure. However, the configuration and setup
> is complex, making them more suitable for long-lived corporate and government
> installations, but less accessible for casual or short-term use. Simple
> username/password authentication would help more users secure more NiFi
> installations beyond anonymous admin access.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
