nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From alopresto <...@git.apache.org>
Subject [GitHub] nifi pull request: NIFI-1614 File Identity Provider implementation
Date Tue, 03 May 2016 16:55:59 GMT
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message