There are a range of things to consider. And yes whatever we do will involve writing code. We also have to find the right place for the bar here.
1. Disable HTTP by default. And if they want to enable HTTP they should also have to make a config change indicating they are fully willing to accept that it is an entirely non secure configuration as far as the application is concerned. 2. Provide a default username/password provider out of the box configured by default and an auto generate self-signed server cert. This means the NiFi server will provide the client browser a cert. It won't be known/trusted so the browser will advise of this. And on startup NiFi can auto generate and log this username and password. It would truly be a single username/password and not some store for various users. We disallow access to all restricted components by default. This default configuration at least means someone cannot start NiFi and it is totally exposed by default while also preserving a pretty simple 'get started' model for the user. They'd have to take action to make it less secure. The option DavidH mentions of mutual auth could work well also and as he mentioned avoids the need for anything special in terms of auth provider which is compelling for us but I do worry about the user experience on that. I'll add to this that I think we cannot afford to wait for a NiFi 2.0 release to take action here. Or that we should expedite a NiFi 2.0 release to take action and that we should just not make the bar for what 2.0 is so high that we never get this done. But frankly I think we could make this change in NiFi 1.15 and document what is happening. For existing installs/configs we'd not be changing anything except maybe when they're using HTTP and don't set the 'no seriously i want this thing wide open option'. Thanks On Wed, Feb 10, 2021 at 6:58 AM David Handermann <exceptionfact...@gmail.com> wrote: > Having NiFi enforce authentication by default seems like the right way to > go, especially given the capabilities of the system. > > Bryan raises a good point about storage of account information, so weighing > the positives and negatives of various identity providers should be > considered. > > Following on Joe's point about disabling plain HTTP, one option could be > generating both client and server certificates and using Mutual TLS for > authentication. This would obviously require installing the client > certificate in a browser, which is not trivial, but could be part of an > installation guide. This approach definitely provides a high barrier of > entry of new users, but provides a strong level of security while avoiding > the need for some other identity provider service to be configured. As > others have mentioned, this seems necessary to address the situation of > someone installing NiFi without a full understanding of the configuration > required, so it is important to keep the audience in mind when evaluating a > solution. > > Regards, > David Handermann > > On Wed, Feb 10, 2021 at 7:39 AM Bryan Bende <bbe...@gmail.com> wrote: > > > Just to clarify, I was not suggesting that we make a default secure > > setup that requires LDAP. > > > > I was just saying that in order to provide a default secure setup, > > we'd have to provide a login identity provider implementation that is > > backed by a file or database table, which in the past we decided > > against. > > > > On Wed, Feb 10, 2021 at 8:28 AM Russell Bateman <r...@windofkeltia.com> > > wrote: > > > > > > I second the concerns expressed, but second especially Bryan's pointing > > > out that requiring LDAP/AD to be set up in order even to begin to use > > > our framework would be a bit onerous for developers just interested in > > > getting work done and a barrier to considering the framework should it > > > be erected a little too high. Should we at least glance at how this is > > > solved by the likes of other projects, Kafka and Cassandra come to > mind, > > > even if it means resorting to a store of a name or two? I didn't find > > > getting into developing with them a pain, but making me jump through > the > > > hoop of setting up LDAP may very well have changed that. > > > > > > These unsecure instances of NiFi out there are not our community's > > > fault. I suppose we're worried about getting splattered by bad press? > > > > > > On 2/10/21 5:47 AM, Bryan Bende wrote: > > > > I agree with the overall idea, although I would think it requires a > > > > major release to make this kind of change to the default behavior. > > > > > > > > Also, we have always avoided NiFi being a store of usernames and > > > > passwords, so we don't have a login provider that uses a local file > or > > > > a database, we've always said you connect to LDAP/AD for that. > > > > > > > > Obviously it can be implemented, but just pointing out that we'd have > > > > to change our stance here if we want to provide a default username > and > > > > password to authenticate with. > > > > > > > > On Tue, Feb 9, 2021 at 11:25 PM Andrew Grande <apere...@gmail.com> > > wrote: > > > >> Mysql has been generating an admin password on default installs for, > > like, > > > >> forever. This workflow should be familiar for many users. > > > >> > > > >> I'd suggest taking the automation tooling into account and how a > > production > > > >> rollout (user-provided password) would fit into the workflow. > > > >> > > > >> Andrew > > > >> > > > >> On Tue, Feb 9, 2021, 8:15 PM Tony Kurc <tk...@apache.org> wrote: > > > >> > > > >>> Joe, > > > >>> In addition to your suggestions, were you thinking of making this > > processor > > > >>> disabled by default as well? > > > >>> > > > >>> Tony > > > >>> > > > >>> > > > >>> On Tue, Feb 9, 2021, 11:04 PM Joe Witt <joew...@apache.org> wrote: > > > >>> > > > >>>> Team > > > >>>> > > > >>>> While secure by default may not be practical perhaps ‘not > blatantly > > wide > > > >>>> open’ by default should be adopted. > > > >>>> > > > >>>> I think we should consider killing support for http entirely and > > support > > > >>>> only https. We should consider auto generating a user and > password > > and > > > >>>> possibly server cert if nothing is configured and log the > generated > > user > > > >>>> and password. Sure it could still be configured to be non secure > > but > > > >>> that > > > >>>> would truly be an admins fault. Now its just ‘on’ > > > >>>> > > > >>>> This tweet is a great example of why > > > >>>> > > > >>>> https://twitter.com/_escctrl_/status/1359280656174510081?s=21 > > > >>>> > > > >>>> > > > >>>> Who agrees? Who disagrees? Please share ideas. > > > >>>> > > > >>>> Thanks > > > >>>> > > >
