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.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---