Mark, Thanks for clarifying, that makes sense.
Regards, David Handermann On Wed, Feb 10, 2021 at 8:41 AM Mark Payne <[email protected]> wrote: > David, > > My concern was purely around generating client certs and using mutual TLS. > I definitely think we should have a server cert if using username & > password. > > Thanks > -Mark > > > > On Feb 10, 2021, at 9:37 AM, David Handermann < > [email protected]> wrote: > > > > Mark, > > > > Thanks for your perspective on certificate generation, I agree that > > troubleshooting certificates can be confusing due to unclear error > > messaging. Generating self-signed certificates for one-way TLS still > > requires the user to accept the certificate presented, but at least that > is > > more common in various products. Are you concerned about that situation, > > or are you more concerned about the additional challenges of mutual TLS > > authentication? > > > > Generating a random password in absence of any other configuration would > > certainly be easier from a new user perspective. Some of the security > > concerns with password authentication can be mitigated with one-way TLS, > so > > a blending of these approaches, as Joe describes in NIFI-8220, seems > like a > > good way to go. > > > > Regards, > > David Handermann > > > > On Wed, Feb 10, 2021 at 8:23 AM Mark Payne <[email protected]> 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 <[email protected]> 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 < > >> [email protected]> > >>> 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 <[email protected]> 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 < > [email protected] > >>> > >>>>> 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 <[email protected]> > >>>>> 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 <[email protected]> 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 <[email protected]> > 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 > >>>>>>>>>> > >>>>> > >>>> > >> > >> > >
