[
https://issues.apache.org/jira/browse/NIFI-13878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17891554#comment-17891554
]
David Handermann commented on NIFI-13878:
-----------------------------------------
Thanks for the reply [~deragon].
I appreciate the willingness to put forward a pull request, but it is the type
of change that would require more consideration that just changing the
X509AuthenticationFilter.
As mentioned originally, ignoring the client certificate in
X509AuthenticationFilter would break node to node communication for clustered
deployments. Although it might be possible to consider the configuration option
to support standalone deployments, the potential confusion of such a
configuration property presents a number of concerns.
There might be a potential way forward that involves preferring the
authentication token over the present certificate, when OIDC is configured. A
solution along those lines should provide a more maintainable and coherent
configuration strategy, but it will involve a closer review of the Spring
Security filter chain, and the impact on all authentication scenarios.
It is possible to configure the client browser to avoid sending the certificate
to particular addresses, which would work, although I acknowledge that requires
configuration at the end-user level. Does your certificate authority
environment have the same issuer for both the NiFi server certificate and the
user certificate? Configuring the NiFi server with a certificate from a
different authority is another potential solution, as NiFi would not accept the
presented client certificate in that scenario.
> Implement an option in nifi.properties that forces authentication with
> OpenID/SSO
> ---------------------------------------------------------------------------------
>
> Key: NIFI-13878
> URL: https://issues.apache.org/jira/browse/NIFI-13878
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Configuration
> Affects Versions: 2.0.0-M4
> Environment: RHEL 9.4 on AWS EC2 with Okta as Identity Provider.
> Reporter: Hans Deragon
> Priority: Major
> Labels: OpenID, certificate
>
> This is a feature request to implement an option in nifi.properties that
> forces authentication with OpenID/SSO, or disable X.509 certificate use for
> authentication.
> We discovered with NiFi 2.0.0-M4 that if a personal X.509 certificate is set
> in user accounts under Windows, that certificate is getting used by NiFi for
> authentication instead of the normal OpenID/SSO headers. The user id in the
> X.509 certificate is not the same as the one in OpenID/SSO (Okta) and thus,
> the person is denied access to NiFi.
> This particular certificate is not meant to be used by NiFi to authenticate
> and authorize users in NiFi even though it is recognized by our Identity
> Provider. We desire that NiFi only authenticate and authorize users with
> OpenID/SSO (which works when I remove the personal certificate from user's
> Windows workstations).
> This issue has been discussed in NiFi User's mailing list but nobody seams to
> come up with a solution to our problem, thus this Jira.
> See: [NiFi 2.0 and possibility to ignore X.509 certificate or force
> authorization with
> OpenID/SSO.|https://lists.apache.org/thread/yphnmj27dpkpdm548mt7dd0jkbjn3wch]
> More details:
> * In
> nifi-framework-bundle/.../web/security/x509/X509AuthenticationFilter.java, I
> commented out code in attemptAuthentication() so it always returns null and
> that works (of course).
> * I attempted to play with the order of addFilterBefore() in
> nifi-framework-bundle/.../web/security/configuration/WebSecurityConfiguration.java
> to hope that OpenID/SSO would always be
> tested first, without success.
> * I had one machine (an AWS EC2) that OpenID/SSO always worked despite the
> certificate. I do not understand why that happened and of course, I compared
> the conf/ directory to another EC2 which uses the certificate instead to
> authenticate the user and found not significant difference, nothing related
> to this topic. I was using Chrome when this happened and clearing the
> cookies did not change the behavior. Using Edge to access the same machine
> would cause the certificate being used. Very odd behavior which I cannot
> explain.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
