I like the idea of the annoying banner. You could place it in the bar, near the area surrounding the "refresh" text for graph control or even take it a step further and add an indicator on the graph for secure or not, similar to the lock on site-to-site connections.
Sent from my iPhone > On Feb 16, 2015, at 8:44 AM, Daniel Bress <[email protected]> wrote: > > Joe, > I think this is a really good idea. > > I think you could solve 1 and 2 by providing an annoying-ish banner/icon > that reminds you that you are running in an insecure mode, that when clicked > takes you to the (to-be-completed) section of the admin guide. > > Dan Bress > Software Engineer > ONYX Consulting Services > > ________________________________________ > From: Mike Drob <[email protected]> > Sent: Sunday, February 15, 2015 9:08 PM > To: [email protected] > Subject: Re: [discuss] How to make nifi secure - or at least not insecure by > default > > 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 >>
