Mark,

To elaborate on Joe's reply, changing the trust store configuration alters
the security profile of NiFi by allowing clients with trusted certificates
to access the system.  Changing the key store and trust store should always
occur in conjunction with changing the authorization configuration.

The Single User Authorizer includes a safety check to prevent configuration
in conjunction with Login Identity Providers other than the Single User
Login Identity Provider.  In the case of certificate authentication,
however, the Login Identity Provider does not apply, since certificate
authentication happens prior to application-level access. Although it might
be possible to add further safety checking in the Single User Authorizer to
also check the username against a particular value, this could introduce
additional coupling between authentication and authorization.  As this is
primarily a configuration problem, and changing the trust store has a
significant impact on the security profile of the system, this particular
scenario does not seem like a significant concern.

Regards,
David Handermann

On Wed, Mar 9, 2022 at 9:55 AM Joe Witt <joe.w...@gmail.com> wrote:

> Mark
>
> The single user authorizer and default setup install is just to avoid
> having wide open systems by default.  So if you want to make changes to
> security settings and do it right you dont' use that mode.  Happy to have
> improvements within that scope of intent but does not sound like anything
> we'd wait for.  When it lands it lands.
>
> Thanks
>
> On Wed, Mar 9, 2022 at 8:49 AM Mark Bean <mark.o.b...@gmail.com> wrote:
>
> > Joe,
> >
> > I just discovered an issue yesterday that might need attention first. I
> > haven't investigated fully yet nor created a ticket because I don't yet
> > fully understand it. However, it appears as though the
> > single-user-authorizer may not be behaving as intended. When I updated
> > nifi.properties to swap the self-signed, auto-generated keystore and
> > truststore with "real" ones, single-user became _every_ user. My
> suspicion
> > is that any user whose browser presents a cert that was signed by a CA in
> > the truststore is allowed in - without even prompting for
> > username/password.
> >
> > It may be considered a configuration error to allow this to happen.
> Still,
> > this seems like extremely dangerous behavior.
> >
> > -Mark
> >
> >
> > On Wed, Mar 9, 2022 at 10:42 AM Joe Witt <joe.w...@gmail.com> wrote:
> >
> > > Team
> > >
> > > We appear to be at a good point to start pulling together the release
> > > candidate for 1.16.
> > >
> > > https://issues.apache.org/jira/projects/NIFI/versions/12350741
> > >
> > > I'm basically waiting for
> > https://issues.apache.org/jira/browse/NIFI-9761
> > > to land then will start pulling together the release.
> > >
> > > Thanks
> > >
> > > On Mon, Feb 14, 2022 at 11:18 AM Joe Witt <joe.w...@gmail.com> wrote:
> > >
> > > > Eduardo
> > > >
> > > > Getting reviewers on the UI/rest/front-end are among the toughest as
> > > > there just aren't as many of those folks.
> > > >
> > > > The reply from Pierre was probably most telling. It looks fine but
> > > > many of us would pause to merge without knowing precisely what the
> > > > implications are.  What happens on a taxed system with many
> > > > CSs...I''ll comment on the PR.
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Mon, Feb 14, 2022 at 11:13 AM Eduardo Fontes
> > > > <eduardo.fon...@gmail.com> wrote:
> > > > >
> > > > > Hi All,
> > > > >
> > > > > Is it possible to include
> > > > https://issues.apache.org/jira/browse/NIFI-8927
> > > > > in release 1.16?
> > > > > I've been asking for a review
> > https://github.com/apache/nifi/pull/5247
> > > > > since AUG/2021 and I don't understand why nobody did it. It's a
> > simple
> > > > and
> > > > > useful UI feature.
> > > > >
> > > > > Peace out.
> > > > > Eduardo Fontes
> > > >
> > >
> >
>

Reply via email to