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