I think the way Joe broke it down makes sense in that there are technically two different parts...
For https, I don't see how we could do that without generating a default self-signed server cert where you'd get a warning in your browser to proceed. I suppose this could be confusing for users, although I feel like most people are familiar with this. For authentication, I suppose we could implement the identity provider in a way that it couldn't/wouldn't really be used for anything else, i.e. don't make it a general purpose database provider, make it only store a single default user/password. If we didn't do https by default, then we'd be providing username/password authentication via plain-text, which doesn't seem great. On Wed, Feb 10, 2021 at 9:30 AM Joe Witt <joe.w...@gmail.com> wrote: > > Created https://issues.apache.org/jira/browse/NIFI-8220 > > I think we need to do this or some variation of it in 1.14 (said 1.15 > before but I meant 1.14). > > Thanks > > On Wed, Feb 10, 2021 at 7:23 AM Mark Payne <marka...@hotmail.com> wrote: > > > I would be in favor of this as well. I agree that there is no need to wait > > for a 2.0 version - there is no inherit backward compatibility challenge > > here. > > Requiring that new application configs be set, etc. I think is completely > > fair game between minor versions. > > > > Personally, though, I would very much stray away from auto-generating > > certificates. For those of us who have dealt with certificates significantly > > In the past, minor configuration issues are easy to address. But for > > someone who hasn’t spent much time dealing with certificates, the error > > messages > > that are often intentionally vague can quickly result in users being > > overwhelmed. This is especially true if browser configurations are already > > setup to > > automatically offer certificates that area already installed - this can > > result in weird error messages about untrusted certificates when the user > > thinks > > they haven’t even provided a certificate, etc. It gets really hairy. > > > > I am more in favor of a default username/password personally. It would > > require implementing a new auth provider. And it’s one that historically we > > have > > avoided implementing because a basic auth type of approach is less secure > > than mutual auth, ldap, etc. But it’s more secure than nothing. > > > > Thanks > > -Mark > > > > > > > On Feb 10, 2021, at 9:13 AM, Joe Witt <joe.w...@gmail.com> wrote: > > > > > > 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 > > >>>>>>>> > > >>> > > >> > > > >
