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 >>>>>>>>>> >>>>> >>>> >> >>
