Inline. On Sun, Feb 15, 2015 at 12:10 PM, Joe Witt <[email protected]> wrote:
> Hello > > Received a note today about this tweet: > > https://twitter.com/silascutler/status/566983203232428033 > > It is a great reminder about our responsibility to provide secure software. > > Out of the box NiFi starts up in a non-secure mode that is an HTTP > port to which anyone that can access it can command and control nifi > as an anonymous user. > > We do provide configuration options for setting up proper HTTPS with > 2-way SSL where the client's browser can establish trust in the > server, the server can establish trust in the client, the server can > establish the client identity by pulling the DN from the cert, and the > server can authorize the user for various roles based on a pluggable > authorization scheme. > > The basic dilemma is how can we best balance out of the box usability > and approach-ability with security. > > Ideas I'd propose: > 1) In the UI provide a constant (and annoying in nature) reminder of a > non-secure config > Sure. 2) Emphasize documentation, tooling, etc.. that makes it easy as > possible for users to establish secure configurations. > Be careful what you bite off here. Off-loading to existing tools is a great way to keep your developers sane. 3) Add support for other identity mechanisms (like what?) > Kerberos? AD? > > If folks have ideas on what the right balance is please share. What > we have now doesn't seem like the right answer and feels irresponsible > knowing that folks will not secure their instances properly. > > Thanks > Joe >
