[ 
https://issues.apache.org/jira/browse/NIFI-13878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17890226#comment-17890226
 ] 

Hans Deragon commented on NIFI-13878:
-------------------------------------

[~exceptionfactory], many thanks for your quick response; it is most 
appreciated.

I understand what you are saying.  However, as stated in the description:

_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)._

Thus, code wise, it should be possible to put a flag in nifi.properties to 
inhibit certificate probing and have 
X509AuthenticationFilter.attemptAuthentication() return null if the flag is set 
to "inhibit".  Probably there is a more elegant way to achieve the same result; 
I am not a NiFi developer so I just conveying ideas here, not a final solution. 
 But at least one solution is possible.

Now, I understand that this might not be very elegant, design wise.  However, 
as you mentioned, the alternative is to have many NiFi Admin having to put out 
the extra infrastructure to implement the reverse proxy, consuming needlessly 
extra CPU and memory to get around this problem.  Sounds to me a flag like the 
one I suggest would save a lot of pain around the world for the decades to come.

Have I, by any chance, convince you? :D

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

Reply via email to